先说一段我自己的经历。早年第一次给项目加定时任务第一反应是去网上搜“Python定时框架”最后挑了个功能齐全的调度库配置写了几十行后来发现项目里真正需要的只是每10分钟检查一次目录有没有新文件。同事用三行代码就搞定了我当时挺受打击的。这件事给我最大的教训是Python3里的定时任务关键不是选一个多么复杂的框架而是先搞清楚围绕“定时”这件事本来就存在的几种基础实现方式。本文就把这些方式一次讲透time.sleep跑循环、threading.Timer起后台线程、schedule库做轻量调度、crontab做系统级定时。每种方式的适用场景、完整代码、容易踩的坑我都会结合自己实际用过的经验展开看完之后遇到定时需求可以直接对号入座。1. 定时任务在内核层面到底在做什么先想明白“定时”的本质很多人一上来就写代码结果写出来的定时任务总出问题根本原因是对“定时”这件事的本质缺少理解。你想想程序本身是不会看钟的CPU只会一条一条执行指令。所谓“定时任务”本质上只包含两件事第一怎么知道当前时刻第二怎么在“到了指定时刻”的时候把对应的任务代码拉起来执行。1.1 所有定时方案都在解决同一个组合问题第一件“知道时间”不难操作系统内核里有一个持续走动的时钟Python里通过time.time()、datetime.now()就能拿到当前时间。难的是第二件怎么让程序在正确的时间“醒过来”去执行任务。你不可能写一个程序无限循环去检查时间那会耗尽CPU。所以系统层面提供的方案通常是两大类一种是“阻塞等待”也就是让当前线程睡到某个时刻内核负责在时间到了之后把它唤醒另一种是“事件注册”把任务注册给某个调度器由调度器在合适的时刻回调。后面要讲的四种实现本质上都是在用这两大类机制的不同组合。1.2 衡量一个定时方案的三个硬指标明白了本质再看各种方案就清楚很多。我评估定时方案一般只看三个硬指标精度任务实际执行时刻和预定时刻之间的偏差。sleep类方案能做到秒级crontab通常只能精确到分钟。漂移连续多次执行后累计误差会越来越大。比如“每10分钟跑一次”如果任务本身执行耗时3分钟你写死sleep(600)那实际的执行间隔其实是603分钟级运行一天下来就会延后很多。阻塞定时逻辑会不会影响主程序的正常工作。你不可能为了定时一个任务把整个Web服务的主线程给卡住。这三个指标基本决定了一种方案适合什么场景。比如精度要求秒级、且任务跟主程序生命周期绑定在一起的就要用进程内方案精度要求分钟级、任务希望独立于Python进程运行、崩溃后系统能兜底的就直接交给crontab。2. 方案一time.sleep 死循环——最朴素的轮询简单但别滥用先说最原始、也最容易理解的一种主进程起一个while True循环定时到点就执行任务没到点就sleep。它把“阻塞等待”用到了极致适合那些本身就是一个常驻脚本、不需要同时处理其他请求的场景。2.1 两种基础写法固定间隔与指定时刻执行固定间隔执行比如说每60秒检查一次某个目录import time import os def check_new_files(): files os.listdir(/tmp/incoming) print(f[{time.strftime(%H:%M:%S)}] 当前目录文件数: {len(files)}) while True: check_new_files() time.sleep(60)指定某个具体时刻执行比如每天凌晨2点跑一次备份import time from datetime import datetime def run_backup(): print(f[{datetime.now()}] 开始执行备份任务...) while True: now datetime.now() target now.replace(hour2, minute0, second0, microsecond0) if now target: # 如果当前时间已经过了凌晨2点说明要等第二天 target target timedelta(days1) sleep_seconds (target - now).total_seconds() time.sleep(sleep_seconds) try: run_backup() except Exception as e: # 这里至少保证异常不会被吞最好落日志 print(f[{datetime.now()}] 备份任务异常: {e})这种写法最直观新手也能一眼看懂。但问题也随之而来。2.2 为什么sleep方案会有“越跑越偏”的漂移问题固定间隔写法里time.sleep(60)只是让当前线程睡60秒但上一轮任务执行本身的耗时完全没算进去。假设check_new_files()执行了3秒那么从任务开始到下一次任务开始实际间隔是63秒。跑一天就是1080秒的偏差约18分钟。时间一长任务会在你完全没预期的时间点执行。修正思路很简单不要“睡固定秒数”而是“睡到下一个目标时刻的差值”。核心是把时间基准从“相对间隔”换成“目标时刻”import time from datetime import datetime, timedelta next_run datetime.now() interval_seconds 60 while True: next_run next_run timedelta(secondsinterval_seconds) now datetime.now() if next_run now: # 说明这一轮循环耗时太久跳过这次调度 next_run now timedelta(secondsinterval_seconds) continue sleep_seconds (next_run - now).total_seconds() time.sleep(sleep_seconds) run_task()这样每次用的是目标时刻差值就算任务偶尔执行了5秒下一轮也会自动重新对齐把误差拉回到单个任务耗时以内不会无限累积。2.3 sleep方案的三个边界阻塞、单任务、扛不住进程重启我在实际用它的时候觉得最不方便的就是阻塞问题。一旦进入sleep主线程就挂了期间收不到外部信号也处理不了别的事。如果你想同时定两个任务一个每10秒一个每5秒死循环里就很别扭——你只能选择把sleep设成两者的最小公倍数再手动判断每个任务是否到点代码马上变复杂。更麻烦的是如果脚本本身是个服务旁边还有网络请求要响应那sleep就完全不合适了。还有一点容易被忽略这种方案的任务调度状态全在进程内存里脚本一重启所有“到点”判断都从头开始。如果脚本是被别人手动重启的而你又指望当天凌晨2点跑备份一旦重启发生在2点之后当天任务就直接跳过了。提示sleep方案只适合“这个脚本就是为这个定时任务而生”的场景比如一个专门做轮询的监控脚本、一个定时清理临时文件的常驻进程。只要还有第二个任务或者还要同时跑一个Web服务建议直接往下看threading.Timer或者schedule。3. 方案二threading.Timer——在后台线程里“睡”不卡主流程threading.Timer是Python标准库自带的一个类实现很简单它本质上是在一个新线程里做sleep睡到指定时间后执行目标函数。好处是定时逻辑不再阻塞主线程主程序该干嘛干嘛。3.1 基本用法一次性延时与循环执行一次性延时任务比如5秒后通知某个接口import threading def send_notification(): print(时间到发送通知) timer threading.Timer(5.0, send_notification) timer.daemon True timer.start() print(主程序继续运行不用等这5秒)要让任务循环执行需要在回调函数里再次创建新的Timerimport threading import time def repeat_job(): print(f[{time.strftime(%H:%M:%S)}] 执行定时任务) # 任务执行完之后创建下一次定时 t threading.Timer(10.0, repeat_job) t.daemon True t.start() t threading.Timer(10.0, repeat_job) t.daemon True t.start() # 主线程继续做别的事比如起一个简单的HTTP服务 while True: time.sleep(1)这里有个关键点创建Timer之后返回的是一个线程对象必须调用start()才开始计时。而且因为要循环执行所以任务函数内部必须自己去启动下一个Timer否则只会触发一次。3.2 底层逻辑它就是Thread加sleep的封装很多人以为Timer是什么高级机制其实看标准库源码就会明白threading.Timer直接继承自threading.Thread核心逻辑就是内部调用self.finished.wait(self.interval)等待结束后再执行函数。wait和sleep一样是阻塞等待只不过它阻塞的是新建出来的那个线程不是主线程。理解这一点对排查问题很有帮助。Timer能让你“把一个人派出去睡10秒睡完了喊你”但它依然是占用一个系统线程的。如果你为了十个定时任务创建了十个Timer后台就有十个线程在那里排队睡觉。数量不多还行量大了线程切换的开销和内存占用都会上来。3.3 用Timer最容易翻车的三个地方第一个坑是daemon属性。默认情况下Timer线程是非守护的也就是说主线程执行完了程序不会退出要等Timer线程也结束才行。如果你写了一个一次性延时通知主流程走完了程序却迟迟不退出多半就是因为忘了设daemonTrue。反过来如果你设了daemonTrue但主线程还有其他循环那Timer执行完之前进程不会退行为倒是正常的。我给自己的建议是函数式任务背后没有长期保存状态一律设置daemonTrue并在主程序里明确管理生命周期。第二个坑是回调函数里不要做太重的任务。Timer能帮你实现“到点触发”但触发后执行的逻辑是串行的。假设任务函数本身跑5分钟在这5分钟内它不会再去“创建下一个Timer”也就是说任务的真实周期是“等待10秒执行5分钟”并不是严格的每10秒一次。所以Timer比较适合轻量级、快进快出的任务。第三个坑是异常处理。回调函数里一旦抛出未捕获的异常线程会直接终止且不会有任何日志输出到主程序可见的地方。很多人用了Timer后任务“莫名消失”最后查下来就是回调里抛了个异常线程死了连个报错都看不到。一定要在任务函数最外层包try/except或者把通用异常捕获封装成装饰器。import threading import traceback def safe_run(func): def wrapper(*args, **kwargs): try: func(*args, **kwargs) except Exception: traceback.print_exc() return wrapper safe_run def repeat_job(): # 你的业务逻辑 passTimer方案比sleep强在“不占主线程”但它本质还是进程内的分工定时器和主程序活在一个进程里。如果进程本身崩了定时任务也就停了。4. 方案三schedule库——用“类自然语言”描述定时开发效率最高的轻量方案如果你搜过Python定时任务一定见过schedule这个库。它最吸引人的地方是把定时语句写得像人话代码可读性极高不熟悉调度系统的人也能几小时上手。4.1 安装与基础示例像读句子一样写调度安装很简单pip install schedule即可。基本用法如下import schedule import time def job(): print(f[{time.strftime(%H:%M:%S)}] 每10分钟执行一次) schedule.every(10).minutes.do(job) def report(): print(f[{time.strftime(%H:%M:%S)}] 每天14:30生成报表) schedule.every().day.at(14:30).do(report) while True: schedule.run_pending() time.sleep(0.5)every(10).minutes.do(job)读起来就是“每10分钟做一次job”every().day.at(14:30)就是“每天14:30”这种表达方式基本不需要查文档。4.2 它到底怎么做到的背后依然是轮询schedule库里没有用到操作系统的定时器底层机制非常简单它会维护一个任务列表每个任务记录下一次应该运行的时间。主循环里每0.5秒调用一次run_pending()这个函数会遍历任务表把当前时间大于等于任务预定时间的任务挑出来执行然后更新下一次预定时间。所以本质上schedule是在用一个高频的“秒级轮询”模拟分钟级、小时级的调度。理解这一点对估算精度很有帮助。你调用run_pending()的频率决定了任务触发的精度上限。如果你在循环里sleep(1)那么任务的触发误差最多也就1秒左右。对于“每10分钟跑一次”这种任务完全够用。但如果你要求毫秒级触发schedule不合适那是属于事件循环和实时系统的范围。4.3 新旧版本API差异run_pending可能在新环境里“带坑”这是我在升级依赖时吃过亏的地方。schedule在1.2.0版本之后把长期作为主循环入口的run_pending()标记为不推荐使用社区推荐的新写法是run_until()和run_continuously()。旧版常见写法while True: schedule.run_pending() time.sleep(1)新版推荐写法import schedule schedule.every(10).minutes.do(job) schedule.run_until() # 持续运行直到任务被取消或进程退出如果希望调度器在单独的线程里跑import schedule import threading schedule.every(10).minutes.do(job) runner schedule.run_continuously() # 返回一个线程对象 # 主线程继续干别的 # 需要停止时调用 runner.shutdown()除此之外schedule还提供了catch_exceptions参数。默认情况下任务函数抛出的异常会直接终止调度器的连续运行这其实是很多人的大坑——任务函数里一个ZeroDivisionError调度器就停了后续所有任务都不再执行。建议显式设置异常捕获def handle_error(task, e): print(f任务 {task} 执行失败错误: {e}) schedule.every(10).minutes.do(job).catch_exceptions(handle_error)或者最简单粗暴的还是在任务函数里自己包一层try/except无论调度器怎么变任务自身的行为是可预期的。4.4 schedule适合什么场景schedule的定位非常明确进程内的中轻量级定时调度目标是让开发效率最高代码最易读。我个人的使用习惯是任务周期从每分钟到每天不等任务数不超过几十个调度逻辑和主进程的生命周期绑在一起。比如爬虫脚本里定时抓页面、数据同步脚本里定时拉接口、后台服务里定时刷新缓存这些用schedule都会很顺手。它的主要限制是调度状态在内存里进程重启需要重新注册而且进程挂了任务也就没了。如果你需要“脚本死了系统还会帮我重新跑起来”的能力就得看第四种方案。注意schedule的run_pending()在1.2.0之后被标记为不推荐但很多老项目仍在使用。升级库版本之前一定要看一遍项目的调度主循环写法避免依赖升级后行为不一致。5. 方案四crontab——把Python脚本交给操作系统稳定性天花板最高crontab不是Python内部的东西而是Linux/macOS系统层面的定时任务机制。它的核心思路是把Python脚本当作一个独立进程由系统的crond守护进程在指定时刻自动拉起来运行。这种方式的稳定性和独立性是前面三种进程内方案比不了的。5.1 一个标准crontab条目是怎么组成的先用crontab -e编辑当前用户的定时任务表每一行就是一个定时任务。条目的格式是五个时间字段加一个命令分 时 日 月 周 命令 0 2 * * * /usr/bin/python3 /home/me/scripts/daily_backup.py /home/me/logs/backup.log 21上面的例子表示“每天凌晨2点0分执行一次daily_backup.py脚本标准输出和错误都追加到backup.log”。五个时间字段分别代表分钟0-59、小时0-23、日1-31、月1-12、星期0-70和7都代表周日。*号代表任意取值。如果你只想在每周一早上9点执行0 9 * * 1 /usr/bin/python3 /home/me/scripts/weekly_report.py想每5分钟执行一次*/5 * * * * /usr/bin/python3 /home/me/scripts/check_health.py5.2 从crontab跑Python最容易翻车的四个环境问题我见过很多人写好了crontab却发现脚本能手动跑、定时跑就不行最后基本都是环境变量问题。这里有几个经验必须记住第一crontab执行时使用的环境变量非常精简PATH一般只有/usr/bin:/bin不会有你在终端里配置的那些路径。如果你在脚本里调用某个用pip install --user安装的命令很可能在定时执行时找不到命令。解决办法有两个脚本里尽量用绝对路径或者在脚本开头显式设定PATH。import os, sys os.environ[PATH] /usr/local/bin:/usr/bin:/bin os.environ.get(PATH, )第二Python解释器路径要写死。你终端里敲python3能跑不代表crontab能跑到同一个python。建议先执行which python3查一下路径然后crontab里直接用绝对路径。如果你在用虚拟环境也要把虚拟环境里的python路径写进去否则脚本import不到你装的库。第三工作目录会被重置。crontab执行脚本时当前工作目录一般是用户主目录不是你写脚本时的目录。如果你的脚本里有相对路径操作比如open(data.json)极容易因为找不到文件报错。最稳妥的做法是脚本开头主动切换绝对目录import os BASE_DIR /home/me/scripts os.chdir(BASE_DIR)第四日志默认丢失。crontab的任务如果没做重定向输出不会显示在任何地方。遇到脚本出问题你连错误都看不到。所以每条crontab命令后面都建议加上日志重定向这是排查问题的基础。5.3 和进程内调度相比crontab赢在独立于Python进程前面说到sleep、Timer、schedule都是进程内方案一个共同缺点是如果Python进程崩溃、被杀掉、或者服务器重启后你没设置开机自启定时任务就全没了。crontab不一样调度逻辑由系统的守护进程管理你只需要在crontab表中登记好命令系统到点就会尝试拉起脚本。哪怕脚本自己执行到一半崩了也只会影响当前这一次不会影响下一次调度。脚本是一次性的独立进程跑完就退出不存在常驻内存的问题。这就决定了crontab特别适合那种“周期较长、需要独立运行、失败也要有下一轮机会”的任务比如每天备份数据库、每周汇总日志、每小时拉取数据到仓库。它的精度受限于分钟级所以不适合“每30秒刷新缓存”的短周期场景。5.4 Windows下的替代方案任务计划程序如果你在Windows环境对应crontab的是“任务计划程序”。使用思路一样把Python脚本作为独立进程由系统在指定时间拉起。可以在图形界面里创建基本任务也可以直接用命令行注册schtasks /create /tn DailyBackup /tr C:\Python39\python.exe C:\scripts\backup.py /sc daily /st 02:00参数含义分别是任务名称、要执行的程序、计划类型daily、开始时间02:00。Windows下也注意同样的问题Python解释器路径、工作目录、日志输出。不要以为跨了系统那些坑就会消失。6. 四种方案的选型对照以及我写生产级定时任务前会补的几件事前面技术细节讲得差不多了最后我习惯用一张表来做选型决策。这张表是我自己总结的把每种方案的关键属性列出来一眼就能看出差距。6.1 一张表看懂四种方式的差异方案实现机制精度是否阻塞主流程是否依赖Python进程存活典型场景time.sleep循环主线程阻塞等待秒级是是单任务常驻脚本threading.Timer后台线程阻塞等待秒级否单线程不阻塞是少量定时任务主程序同时做别的事schedule库内存任务表轮询秒级取决于调用频率否配合线程可解除阻塞是进程内多任务、周期短、代码可读性优先crontab系统守护进程调度分钟级否否长期稳定、独立进程、服务器级任务6.2 我的选型逻辑先看任务生命周期再看是否需要独立运行选型我没用复杂的打分表就两个问题第一任务是否必须在Python进程跑的时候才有效比如“Web服务的缓存每60秒刷新一次”这种任务跟服务进程天然绑定进程都不在了刷新缓存本来就无意义。这种情况就从进程内方案里选——任务少且轻用threading.Timer任务多且周期不可控用schedule。第二任务是否希望“脚本挂了系统还帮我跑”比如“每天凌晨2点备份数据库”这种任务跟Python进程没关系备份是系统级别的需求。直接上crontab别在Python里折腾常驻进程。如果你还担心服务器重启后crontab里的任务不恢复——实际上crond本身就是开机启动的常驻守护进程crontab表里的任务在系统启动后就会重新生效不需要你额外处理。睡眠类方案里的time.sleep我现在只在一种情况下会主动用某个临时脚本本身就是为单次监控或轮询写的生命周期极其短跑完就删除。其余时候线程里的threading.Timer或schedule都不会比sleep差。6.3 不管选了哪种上线前都要补的三件事我踩过太多定时任务的坑总结下来无论哪种方案上线前必须补三样东西。第一异常兜底。任务函数里必须捕获所有异常并输出到日志。进程内方案里异常会杀线程、停调度器crontab方案里异常导致脚本退出码非0往往连日志都没有。所以任务函数最外层永远是try/except加日志不能裸跑。第二日志。定时任务最大的特点是“不到执行那一刻不知道有没有出问题”。没有日志出问题只能靠猜。每写一个定时任务先想清楚日志写哪里、保留多久。crontab用文件重定向进程内方案用日志模块。第三防止重复执行。这是特别容易被忽略的。一个任务执行时间过长下一次调度又到了比如备份脚本跑了40分钟但crontab设置成每30分钟执行一次就会导致两个备份进程同时跑轻则资源抢占重则数据错乱。简单的做法是文件锁import os lock_file /tmp/daily_backup.lock if os.path.exists(lock_file): # 上一次任务还没结束直接退出本次执行 sys.exit(0) open(lock_file, w).close() try: run_backup() finally: os.remove(lock_file)文件锁方案虽然朴素但在绝大多数单机定时任务场景下完全够用。如果你需要更可靠的互斥控制可以换成fcntl锁或者基于系统的flock原理是一样的确保同一时刻只有一个任务实例在跑。7. 最后分享一点我用定时任务的经验我已经很少在一套系统里只用一种定时方案了。比较常见的组合是跟业务进程绑定的短周期任务比如缓存刷新、数据预热用schedule在进程内跑跟机器生命周期绑定的系统性任务比如备份、日志归档、数据同步全部扔给crontab。这样既保证了业务逻辑的灵活性又拿到了系统级的稳定性。另外多说一句凡是定时任务设计时都要假设“这一次执行可能会失败甚至可能失败得很难看”所以提前做好异常捕获、日志和重复保护比选哪个方案重要得多。定时任务本身不难难的是让它在无人盯着的时候还能稳稳地跑下去。
先说一段我自己的经历。早年第一次给项目加定时任务第一反应是去网上搜“Python定时框架”最后挑了个功能齐全的调度库配置写了几十行后来发现项目里真正需要的只是每10分钟检查一次目录有没有新文件。同事用三行代码就搞定了我当时挺受打击的。这件事给我最大的教训是Python3里的定时任务关键不是选一个多么复杂的框架而是先搞清楚围绕“定时”这件事本来就存在的几种基础实现方式。本文就把这些方式一次讲透time.sleep跑循环、threading.Timer起后台线程、schedule库做轻量调度、crontab做系统级定时。每种方式的适用场景、完整代码、容易踩的坑我都会结合自己实际用过的经验展开看完之后遇到定时需求可以直接对号入座。1. 定时任务在内核层面到底在做什么先想明白“定时”的本质很多人一上来就写代码结果写出来的定时任务总出问题根本原因是对“定时”这件事的本质缺少理解。你想想程序本身是不会看钟的CPU只会一条一条执行指令。所谓“定时任务”本质上只包含两件事第一怎么知道当前时刻第二怎么在“到了指定时刻”的时候把对应的任务代码拉起来执行。1.1 所有定时方案都在解决同一个组合问题第一件“知道时间”不难操作系统内核里有一个持续走动的时钟Python里通过time.time()、datetime.now()就能拿到当前时间。难的是第二件怎么让程序在正确的时间“醒过来”去执行任务。你不可能写一个程序无限循环去检查时间那会耗尽CPU。所以系统层面提供的方案通常是两大类一种是“阻塞等待”也就是让当前线程睡到某个时刻内核负责在时间到了之后把它唤醒另一种是“事件注册”把任务注册给某个调度器由调度器在合适的时刻回调。后面要讲的四种实现本质上都是在用这两大类机制的不同组合。1.2 衡量一个定时方案的三个硬指标明白了本质再看各种方案就清楚很多。我评估定时方案一般只看三个硬指标精度任务实际执行时刻和预定时刻之间的偏差。sleep类方案能做到秒级crontab通常只能精确到分钟。漂移连续多次执行后累计误差会越来越大。比如“每10分钟跑一次”如果任务本身执行耗时3分钟你写死sleep(600)那实际的执行间隔其实是603分钟级运行一天下来就会延后很多。阻塞定时逻辑会不会影响主程序的正常工作。你不可能为了定时一个任务把整个Web服务的主线程给卡住。这三个指标基本决定了一种方案适合什么场景。比如精度要求秒级、且任务跟主程序生命周期绑定在一起的就要用进程内方案精度要求分钟级、任务希望独立于Python进程运行、崩溃后系统能兜底的就直接交给crontab。2. 方案一time.sleep 死循环——最朴素的轮询简单但别滥用先说最原始、也最容易理解的一种主进程起一个while True循环定时到点就执行任务没到点就sleep。它把“阻塞等待”用到了极致适合那些本身就是一个常驻脚本、不需要同时处理其他请求的场景。2.1 两种基础写法固定间隔与指定时刻执行固定间隔执行比如说每60秒检查一次某个目录import time import os def check_new_files(): files os.listdir(/tmp/incoming) print(f[{time.strftime(%H:%M:%S)}] 当前目录文件数: {len(files)}) while True: check_new_files() time.sleep(60)指定某个具体时刻执行比如每天凌晨2点跑一次备份import time from datetime import datetime def run_backup(): print(f[{datetime.now()}] 开始执行备份任务...) while True: now datetime.now() target now.replace(hour2, minute0, second0, microsecond0) if now target: # 如果当前时间已经过了凌晨2点说明要等第二天 target target timedelta(days1) sleep_seconds (target - now).total_seconds() time.sleep(sleep_seconds) try: run_backup() except Exception as e: # 这里至少保证异常不会被吞最好落日志 print(f[{datetime.now()}] 备份任务异常: {e})这种写法最直观新手也能一眼看懂。但问题也随之而来。2.2 为什么sleep方案会有“越跑越偏”的漂移问题固定间隔写法里time.sleep(60)只是让当前线程睡60秒但上一轮任务执行本身的耗时完全没算进去。假设check_new_files()执行了3秒那么从任务开始到下一次任务开始实际间隔是63秒。跑一天就是1080秒的偏差约18分钟。时间一长任务会在你完全没预期的时间点执行。修正思路很简单不要“睡固定秒数”而是“睡到下一个目标时刻的差值”。核心是把时间基准从“相对间隔”换成“目标时刻”import time from datetime import datetime, timedelta next_run datetime.now() interval_seconds 60 while True: next_run next_run timedelta(secondsinterval_seconds) now datetime.now() if next_run now: # 说明这一轮循环耗时太久跳过这次调度 next_run now timedelta(secondsinterval_seconds) continue sleep_seconds (next_run - now).total_seconds() time.sleep(sleep_seconds) run_task()这样每次用的是目标时刻差值就算任务偶尔执行了5秒下一轮也会自动重新对齐把误差拉回到单个任务耗时以内不会无限累积。2.3 sleep方案的三个边界阻塞、单任务、扛不住进程重启我在实际用它的时候觉得最不方便的就是阻塞问题。一旦进入sleep主线程就挂了期间收不到外部信号也处理不了别的事。如果你想同时定两个任务一个每10秒一个每5秒死循环里就很别扭——你只能选择把sleep设成两者的最小公倍数再手动判断每个任务是否到点代码马上变复杂。更麻烦的是如果脚本本身是个服务旁边还有网络请求要响应那sleep就完全不合适了。还有一点容易被忽略这种方案的任务调度状态全在进程内存里脚本一重启所有“到点”判断都从头开始。如果脚本是被别人手动重启的而你又指望当天凌晨2点跑备份一旦重启发生在2点之后当天任务就直接跳过了。提示sleep方案只适合“这个脚本就是为这个定时任务而生”的场景比如一个专门做轮询的监控脚本、一个定时清理临时文件的常驻进程。只要还有第二个任务或者还要同时跑一个Web服务建议直接往下看threading.Timer或者schedule。3. 方案二threading.Timer——在后台线程里“睡”不卡主流程threading.Timer是Python标准库自带的一个类实现很简单它本质上是在一个新线程里做sleep睡到指定时间后执行目标函数。好处是定时逻辑不再阻塞主线程主程序该干嘛干嘛。3.1 基本用法一次性延时与循环执行一次性延时任务比如5秒后通知某个接口import threading def send_notification(): print(时间到发送通知) timer threading.Timer(5.0, send_notification) timer.daemon True timer.start() print(主程序继续运行不用等这5秒)要让任务循环执行需要在回调函数里再次创建新的Timerimport threading import time def repeat_job(): print(f[{time.strftime(%H:%M:%S)}] 执行定时任务) # 任务执行完之后创建下一次定时 t threading.Timer(10.0, repeat_job) t.daemon True t.start() t threading.Timer(10.0, repeat_job) t.daemon True t.start() # 主线程继续做别的事比如起一个简单的HTTP服务 while True: time.sleep(1)这里有个关键点创建Timer之后返回的是一个线程对象必须调用start()才开始计时。而且因为要循环执行所以任务函数内部必须自己去启动下一个Timer否则只会触发一次。3.2 底层逻辑它就是Thread加sleep的封装很多人以为Timer是什么高级机制其实看标准库源码就会明白threading.Timer直接继承自threading.Thread核心逻辑就是内部调用self.finished.wait(self.interval)等待结束后再执行函数。wait和sleep一样是阻塞等待只不过它阻塞的是新建出来的那个线程不是主线程。理解这一点对排查问题很有帮助。Timer能让你“把一个人派出去睡10秒睡完了喊你”但它依然是占用一个系统线程的。如果你为了十个定时任务创建了十个Timer后台就有十个线程在那里排队睡觉。数量不多还行量大了线程切换的开销和内存占用都会上来。3.3 用Timer最容易翻车的三个地方第一个坑是daemon属性。默认情况下Timer线程是非守护的也就是说主线程执行完了程序不会退出要等Timer线程也结束才行。如果你写了一个一次性延时通知主流程走完了程序却迟迟不退出多半就是因为忘了设daemonTrue。反过来如果你设了daemonTrue但主线程还有其他循环那Timer执行完之前进程不会退行为倒是正常的。我给自己的建议是函数式任务背后没有长期保存状态一律设置daemonTrue并在主程序里明确管理生命周期。第二个坑是回调函数里不要做太重的任务。Timer能帮你实现“到点触发”但触发后执行的逻辑是串行的。假设任务函数本身跑5分钟在这5分钟内它不会再去“创建下一个Timer”也就是说任务的真实周期是“等待10秒执行5分钟”并不是严格的每10秒一次。所以Timer比较适合轻量级、快进快出的任务。第三个坑是异常处理。回调函数里一旦抛出未捕获的异常线程会直接终止且不会有任何日志输出到主程序可见的地方。很多人用了Timer后任务“莫名消失”最后查下来就是回调里抛了个异常线程死了连个报错都看不到。一定要在任务函数最外层包try/except或者把通用异常捕获封装成装饰器。import threading import traceback def safe_run(func): def wrapper(*args, **kwargs): try: func(*args, **kwargs) except Exception: traceback.print_exc() return wrapper safe_run def repeat_job(): # 你的业务逻辑 passTimer方案比sleep强在“不占主线程”但它本质还是进程内的分工定时器和主程序活在一个进程里。如果进程本身崩了定时任务也就停了。4. 方案三schedule库——用“类自然语言”描述定时开发效率最高的轻量方案如果你搜过Python定时任务一定见过schedule这个库。它最吸引人的地方是把定时语句写得像人话代码可读性极高不熟悉调度系统的人也能几小时上手。4.1 安装与基础示例像读句子一样写调度安装很简单pip install schedule即可。基本用法如下import schedule import time def job(): print(f[{time.strftime(%H:%M:%S)}] 每10分钟执行一次) schedule.every(10).minutes.do(job) def report(): print(f[{time.strftime(%H:%M:%S)}] 每天14:30生成报表) schedule.every().day.at(14:30).do(report) while True: schedule.run_pending() time.sleep(0.5)every(10).minutes.do(job)读起来就是“每10分钟做一次job”every().day.at(14:30)就是“每天14:30”这种表达方式基本不需要查文档。4.2 它到底怎么做到的背后依然是轮询schedule库里没有用到操作系统的定时器底层机制非常简单它会维护一个任务列表每个任务记录下一次应该运行的时间。主循环里每0.5秒调用一次run_pending()这个函数会遍历任务表把当前时间大于等于任务预定时间的任务挑出来执行然后更新下一次预定时间。所以本质上schedule是在用一个高频的“秒级轮询”模拟分钟级、小时级的调度。理解这一点对估算精度很有帮助。你调用run_pending()的频率决定了任务触发的精度上限。如果你在循环里sleep(1)那么任务的触发误差最多也就1秒左右。对于“每10分钟跑一次”这种任务完全够用。但如果你要求毫秒级触发schedule不合适那是属于事件循环和实时系统的范围。4.3 新旧版本API差异run_pending可能在新环境里“带坑”这是我在升级依赖时吃过亏的地方。schedule在1.2.0版本之后把长期作为主循环入口的run_pending()标记为不推荐使用社区推荐的新写法是run_until()和run_continuously()。旧版常见写法while True: schedule.run_pending() time.sleep(1)新版推荐写法import schedule schedule.every(10).minutes.do(job) schedule.run_until() # 持续运行直到任务被取消或进程退出如果希望调度器在单独的线程里跑import schedule import threading schedule.every(10).minutes.do(job) runner schedule.run_continuously() # 返回一个线程对象 # 主线程继续干别的 # 需要停止时调用 runner.shutdown()除此之外schedule还提供了catch_exceptions参数。默认情况下任务函数抛出的异常会直接终止调度器的连续运行这其实是很多人的大坑——任务函数里一个ZeroDivisionError调度器就停了后续所有任务都不再执行。建议显式设置异常捕获def handle_error(task, e): print(f任务 {task} 执行失败错误: {e}) schedule.every(10).minutes.do(job).catch_exceptions(handle_error)或者最简单粗暴的还是在任务函数里自己包一层try/except无论调度器怎么变任务自身的行为是可预期的。4.4 schedule适合什么场景schedule的定位非常明确进程内的中轻量级定时调度目标是让开发效率最高代码最易读。我个人的使用习惯是任务周期从每分钟到每天不等任务数不超过几十个调度逻辑和主进程的生命周期绑在一起。比如爬虫脚本里定时抓页面、数据同步脚本里定时拉接口、后台服务里定时刷新缓存这些用schedule都会很顺手。它的主要限制是调度状态在内存里进程重启需要重新注册而且进程挂了任务也就没了。如果你需要“脚本死了系统还会帮我重新跑起来”的能力就得看第四种方案。注意schedule的run_pending()在1.2.0之后被标记为不推荐但很多老项目仍在使用。升级库版本之前一定要看一遍项目的调度主循环写法避免依赖升级后行为不一致。5. 方案四crontab——把Python脚本交给操作系统稳定性天花板最高crontab不是Python内部的东西而是Linux/macOS系统层面的定时任务机制。它的核心思路是把Python脚本当作一个独立进程由系统的crond守护进程在指定时刻自动拉起来运行。这种方式的稳定性和独立性是前面三种进程内方案比不了的。5.1 一个标准crontab条目是怎么组成的先用crontab -e编辑当前用户的定时任务表每一行就是一个定时任务。条目的格式是五个时间字段加一个命令分 时 日 月 周 命令 0 2 * * * /usr/bin/python3 /home/me/scripts/daily_backup.py /home/me/logs/backup.log 21上面的例子表示“每天凌晨2点0分执行一次daily_backup.py脚本标准输出和错误都追加到backup.log”。五个时间字段分别代表分钟0-59、小时0-23、日1-31、月1-12、星期0-70和7都代表周日。*号代表任意取值。如果你只想在每周一早上9点执行0 9 * * 1 /usr/bin/python3 /home/me/scripts/weekly_report.py想每5分钟执行一次*/5 * * * * /usr/bin/python3 /home/me/scripts/check_health.py5.2 从crontab跑Python最容易翻车的四个环境问题我见过很多人写好了crontab却发现脚本能手动跑、定时跑就不行最后基本都是环境变量问题。这里有几个经验必须记住第一crontab执行时使用的环境变量非常精简PATH一般只有/usr/bin:/bin不会有你在终端里配置的那些路径。如果你在脚本里调用某个用pip install --user安装的命令很可能在定时执行时找不到命令。解决办法有两个脚本里尽量用绝对路径或者在脚本开头显式设定PATH。import os, sys os.environ[PATH] /usr/local/bin:/usr/bin:/bin os.environ.get(PATH, )第二Python解释器路径要写死。你终端里敲python3能跑不代表crontab能跑到同一个python。建议先执行which python3查一下路径然后crontab里直接用绝对路径。如果你在用虚拟环境也要把虚拟环境里的python路径写进去否则脚本import不到你装的库。第三工作目录会被重置。crontab执行脚本时当前工作目录一般是用户主目录不是你写脚本时的目录。如果你的脚本里有相对路径操作比如open(data.json)极容易因为找不到文件报错。最稳妥的做法是脚本开头主动切换绝对目录import os BASE_DIR /home/me/scripts os.chdir(BASE_DIR)第四日志默认丢失。crontab的任务如果没做重定向输出不会显示在任何地方。遇到脚本出问题你连错误都看不到。所以每条crontab命令后面都建议加上日志重定向这是排查问题的基础。5.3 和进程内调度相比crontab赢在独立于Python进程前面说到sleep、Timer、schedule都是进程内方案一个共同缺点是如果Python进程崩溃、被杀掉、或者服务器重启后你没设置开机自启定时任务就全没了。crontab不一样调度逻辑由系统的守护进程管理你只需要在crontab表中登记好命令系统到点就会尝试拉起脚本。哪怕脚本自己执行到一半崩了也只会影响当前这一次不会影响下一次调度。脚本是一次性的独立进程跑完就退出不存在常驻内存的问题。这就决定了crontab特别适合那种“周期较长、需要独立运行、失败也要有下一轮机会”的任务比如每天备份数据库、每周汇总日志、每小时拉取数据到仓库。它的精度受限于分钟级所以不适合“每30秒刷新缓存”的短周期场景。5.4 Windows下的替代方案任务计划程序如果你在Windows环境对应crontab的是“任务计划程序”。使用思路一样把Python脚本作为独立进程由系统在指定时间拉起。可以在图形界面里创建基本任务也可以直接用命令行注册schtasks /create /tn DailyBackup /tr C:\Python39\python.exe C:\scripts\backup.py /sc daily /st 02:00参数含义分别是任务名称、要执行的程序、计划类型daily、开始时间02:00。Windows下也注意同样的问题Python解释器路径、工作目录、日志输出。不要以为跨了系统那些坑就会消失。6. 四种方案的选型对照以及我写生产级定时任务前会补的几件事前面技术细节讲得差不多了最后我习惯用一张表来做选型决策。这张表是我自己总结的把每种方案的关键属性列出来一眼就能看出差距。6.1 一张表看懂四种方式的差异方案实现机制精度是否阻塞主流程是否依赖Python进程存活典型场景time.sleep循环主线程阻塞等待秒级是是单任务常驻脚本threading.Timer后台线程阻塞等待秒级否单线程不阻塞是少量定时任务主程序同时做别的事schedule库内存任务表轮询秒级取决于调用频率否配合线程可解除阻塞是进程内多任务、周期短、代码可读性优先crontab系统守护进程调度分钟级否否长期稳定、独立进程、服务器级任务6.2 我的选型逻辑先看任务生命周期再看是否需要独立运行选型我没用复杂的打分表就两个问题第一任务是否必须在Python进程跑的时候才有效比如“Web服务的缓存每60秒刷新一次”这种任务跟服务进程天然绑定进程都不在了刷新缓存本来就无意义。这种情况就从进程内方案里选——任务少且轻用threading.Timer任务多且周期不可控用schedule。第二任务是否希望“脚本挂了系统还帮我跑”比如“每天凌晨2点备份数据库”这种任务跟Python进程没关系备份是系统级别的需求。直接上crontab别在Python里折腾常驻进程。如果你还担心服务器重启后crontab里的任务不恢复——实际上crond本身就是开机启动的常驻守护进程crontab表里的任务在系统启动后就会重新生效不需要你额外处理。睡眠类方案里的time.sleep我现在只在一种情况下会主动用某个临时脚本本身就是为单次监控或轮询写的生命周期极其短跑完就删除。其余时候线程里的threading.Timer或schedule都不会比sleep差。6.3 不管选了哪种上线前都要补的三件事我踩过太多定时任务的坑总结下来无论哪种方案上线前必须补三样东西。第一异常兜底。任务函数里必须捕获所有异常并输出到日志。进程内方案里异常会杀线程、停调度器crontab方案里异常导致脚本退出码非0往往连日志都没有。所以任务函数最外层永远是try/except加日志不能裸跑。第二日志。定时任务最大的特点是“不到执行那一刻不知道有没有出问题”。没有日志出问题只能靠猜。每写一个定时任务先想清楚日志写哪里、保留多久。crontab用文件重定向进程内方案用日志模块。第三防止重复执行。这是特别容易被忽略的。一个任务执行时间过长下一次调度又到了比如备份脚本跑了40分钟但crontab设置成每30分钟执行一次就会导致两个备份进程同时跑轻则资源抢占重则数据错乱。简单的做法是文件锁import os lock_file /tmp/daily_backup.lock if os.path.exists(lock_file): # 上一次任务还没结束直接退出本次执行 sys.exit(0) open(lock_file, w).close() try: run_backup() finally: os.remove(lock_file)文件锁方案虽然朴素但在绝大多数单机定时任务场景下完全够用。如果你需要更可靠的互斥控制可以换成fcntl锁或者基于系统的flock原理是一样的确保同一时刻只有一个任务实例在跑。7. 最后分享一点我用定时任务的经验我已经很少在一套系统里只用一种定时方案了。比较常见的组合是跟业务进程绑定的短周期任务比如缓存刷新、数据预热用schedule在进程内跑跟机器生命周期绑定的系统性任务比如备份、日志归档、数据同步全部扔给crontab。这样既保证了业务逻辑的灵活性又拿到了系统级的稳定性。另外多说一句凡是定时任务设计时都要假设“这一次执行可能会失败甚至可能失败得很难看”所以提前做好异常捕获、日志和重复保护比选哪个方案重要得多。定时任务本身不难难的是让它在无人盯着的时候还能稳稳地跑下去。
