Python定时任务库对比：轻量首选

schedule适合单进程脚本级定时任务，轻量无依赖但无持久化、无分布式、不支持毫秒级精度且任务串行执行；APScheduler适用于需可靠性与扩展性的场景；Huey适用于定时+异步+队列混合需求。

schedule 适合「单进程、脚本级」定时任务

它就是个纯 Python 的轻量调度器，不带后台服务、不持久化、不支持分布式——但正因如此，启动快、无依赖、调试直观。你写个爬虫脚本每天凌晨拉一次数据，schedule 就够了。

常见错误现象：while True: schedule.run_pending(); time.sleep(1) 被写在主线程末尾，结果脚本一跑完就退出；或者用 threading.Timer 包裹后没 hold 住主线程，任务根本没执行。

• 必须显式维持运行：加 while True: + time.sleep()，且不能放在函数里就返回
• 不支持秒级以下精度（最小粒度是秒），every(5).seconds 是合法的，every(500).milliseconds 不行
• 所有任务都在同一进程、同一线程执行，一个任务卡死，后续全阻塞
• 没有日志、无失败重试、无任务状态查询，出问题只能靠 print 或 logging 手动埋点

APScheduler 在「需要可靠性和扩展性」时才值得引入

APScheduler 功能全，但复杂度也高。它支持内存/SQLAlchemy/MongoDB 多种 jobstore，能选 ThreadPoolExecutor 或 ProcessPoolExecutor，还能对接 asyncio。但这些能力，90% 的小项目根本用不上。

使用场景：你有多个定时任务，其中一些要失败重试、有些需记录执行历史、有些得跨重启恢复——这时才该考虑它。

• 默认使用 MemoryJobStore，进程一挂，所有任务就丢，别误以为“它自带持久化”
• BackgroundScheduler 启动后不阻塞主线程，但主线程若结束（比如脚本跑完），后台线程也会被杀，得用 wait() 或信号监听兜底
• add_job() 的 trigger 参数容易混淆：CronTrigger 支持 day_of_week='mon-fri'，而 IntervalTrigger 只认 weeks/days/hours，混用会静默失败
• 和 Flask/Django 集成时，别在应用工厂函数里反复调用 start()，否则可能启多个 scheduler 实例，触发重复执行

Huey 解决的是「定时 + 异步 + 队列」混合需求

如果你的任务本身就需要异步执行（比如发邮件、调外部 API、生成报表），又恰好要定时触发，那 Huey 是比前两者更自然的选择。它本质是个轻量任务队列，定时只是它的插件能力之一。

性能影响：它依赖 Redis（或 SQLite），每次调度都走一次 Redis push/pop，比 schedule 多一层网络/IO 开销；但换来的是任务隔离——一个任务崩溃不影响其他任务，还能查执行记录、手动重试。

• @huey.periodic_task(crontab(minute='*/5')) 写法看着像 cron，但底层不是系统 crond，而是 Huey 自己轮询 Redis 的 schedule 结构
• 必须运行 huey_consumer 进程来消费任务，光写装饰器不启动 consumer，定时任务永远不会执行
• SQLite 模式下不支持并发 consumer，Redis 模式下如果多个 consumer 订阅同一个 huey 实例，任务会被重复执行（需确保 name 唯一）
• 它不自动处理时区——crontab() 默认按系统本地时区解析，部署到 UTC 服务器时，hour='9' 实际是 UTC 9 点，不是你本地上午 9 点

选错的代价往往比选慢更麻烦

用 APScheduler 跑一个每小时发条微信通知的脚本，等于扛着消防斧削苹果：配置文件多出三倍，出问题要查 jobstore 锁、executor 队列、trigger 时间计算，而 schedule 一行 print 就能定位卡在哪。

反过来，如果用 schedule 去调度十个需要并发、失败重试、跨天回溯的日志归档任务，不出三天就会开始手写 retry 逻辑、时间戳标记、文件锁——最后代码比直接上 Huey 还难维护。

真正关键的分水岭不在功能列表里，而在「任务失败时，你愿不愿意 ssh 到服务器上手动删临时文件、改时间戳、再敲命令重跑」。愿意，schedule 就够；不愿意，就该换。