APScheduler适合单机轻量定时任务，Celery适合分布式场景；选错会导致任务重复或过度设计。
APScheduler 适合单机、配置即用的定时任务
如果你的 Python 后台部署在一台机器上，没有跨进程/跨机器调度需求，APScheduler 是最直接的选择。它不依赖外部服务，几行代码就能跑起来，适合运维环境简单、任务量不大（比如每分钟一次的数据库清理、小时级报表生成）的场景。
常见错误现象：Scheduler started without any jobs —— 忘记调用 add_job() 或用了 add_job(func, 'interval', minutes=1) 却没传 func；或者用 BackgroundScheduler 时主线程退出导致调度器静默停止。
- 必须显式调用
start()，且主线程不能立即结束（可用time.sleep()或Event().wait()持住） -
MemoryJobStore是默认存储，重启即丢任务；如需持久化，得换SQLAlchemyJobStore并配好数据库 URL - 触发器类型别写错：
'interval'对应周期执行，'cron'支持类 Linux cron 表达式（如hour='9-17', day_of_week='mon-fri'），但注意APScheduler的cron不支持秒级精度 - 函数若在模块顶层定义，要确保导入路径稳定；避免在 Flask/FastAPI 的路由函数里直接
add_job，容易重复注册
Celery + Redis/RabbitMQ 才算真正分布式定时任务
Celery 本身不是定时调度器，它的 celery beat 进程才负责按计划发任务，worker 进程只负责执行。所以“Celery 做定时任务”实际是三件套：broker（如 redis://...）、beat 进程、worker 进程。缺一不可，部署复杂度明显上升。
常见错误现象：Received unregistered task of type 'xxx' —— worker 没加载对应任务模块；或 Connection refused —— beat 和 worker 都连不上 broker；更隐蔽的是 celery beat 时间不同步导致任务延迟触发（尤其跨时区部署时）。
立即学习“Python免费学习笔记（深入）”；
- 必须单独启动
celery -A tasks beat和celery -A tasks worker两个进程，不能合并在一个脚本里靠subprocess启动（信号处理和日志会乱） - 定时规则写在
CELERY_BEAT_SCHEDULE字典里，键名只是标识，值里的'task'必须和@app.task装饰的函数全路径一致（如'myapp.tasks.send_report'） -
crontab(minute='*/5')看似方便，但底层依赖系统时钟，如果 beat 进程卡顿超过 1 分钟，可能跳过某次执行；生产环境建议用interval+ 显式时间判断兜底 - Redis 作 broker 时，
CELERY_RESULT_BACKEND若也设为 Redis，要注意连接数限制和过期策略，否则结果堆积拖慢整个队列
选错方案的典型后果：APScheduler 在多实例下任务重复，Celery 在单机下过度设计
当你的 Flask 应用开了 4 个 Gunicorn worker，每个都初始化一个 APScheduler 实例，那每分钟的备份任务就会被执行 4 次——因为它根本不知道其他进程的存在。反过来，如果只是给内部管理后台加一个每天凌晨同步用户数据的任务，硬上 Celery，等于为 1 个定时点搭起 3 个服务、2 种配置、至少 4 个进程监控项。
性能与兼容性影响很实在：APScheduler 内存占用低、启动快，但无法水平扩展；Celery 天然支持失败重试、优先级、限流、任务链，可轻松对接 Sentry、Prometheus，但 Python 版本敏感（celery 不支持 Python 3.9+ 的某些语法），且 <code>pydantic 1.x 和 2.x 兼容性曾坑过不少人。
- APScheduler 多实例重复问题，没有银弹，要么改用分布式锁（如 Redis lock），要么彻底放弃它、切到 Celery
- Celery 的
task_serializer='json'是安全底线，别轻易切pickle，尤其任务参数含自定义类时，worker 反序列化会报AttributeError: Can't get attribute 'MyClass' on <module '__main__'> - 本地开发调试时，Celery 的
--loglevel=info输出太吵，建议加--pool=solo避免 multiprocessing 带来的 fork 问题
上线前必须验证的三个点
不管选哪个方案，上线前这三件事不做，大概率出问题。
- 确认任务函数能独立运行：把函数拎出来，在 Python shell 里手动调一次，检查数据库连接、文件路径、环境变量是否就绪
- 模拟进程重启：对 APScheduler，杀掉再拉起，看任务是否从断点继续；对 Celery，停掉 beat，等 2 分钟再启，观察是否补发漏掉的周期任务（默认不补，需配
max_interval或手动处理） - 压测真实负载：用
time.time()包裹任务体，记录每次执行耗时；如果平均超 30 秒，APScheduler 的coalesce=True会合并多次触发，而 Celery 的acks_late=True可能导致重复执行
定时任务真正的麻烦不在怎么写，而在怎么让它“每次都按你想的那样发生”。时间、状态、依赖服务的可用性，三者只要一个飘移，结果就偏了。盯着日志比盯着代码更重要。
