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% 的小项目根本用不上。
使用场景：你有多个定时任务，其中一些要失败重试、有些需记录执行历史、有些得跨重启恢复——这时才该考虑它。
立即学习“Python免费学习笔记（深入）”；
- 默认使用
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 就够；不愿意，就该换。
