定时任务中断后需靠持久化状态+主动检查补偿，APScheduler需换SQLAlchemyJobStore并设coalesce=True和足够misfire_grace_time，Celery定时任务需显式配置autoretry_for，schedule须加循环执行run_pending()，所有补偿必须与幂等设计结合。
任务没跑完就被杀掉，怎么补救
Python 定时任务（比如用 APScheduler 或 schedule 库触发的）一旦被强制终止（如进程被 kill -9、容器重启、服务器断电），就彻底丢失上下文——它不会自动重试，也不会记住“该在 10:00 跑但没跑成”。补偿不是靠定时器本身，而是靠外部状态记录 + 主动检查。
- 必须把“是否已执行”这个状态存到持久化介质里，比如数据库某张表的
last_run_at字段或 Redis 的task:send_email:latest键 - 每次任务启动前，先查这个状态：如果距离计划时间已超阈值（比如 5 分钟），且状态显示未完成，就主动执行一次补偿逻辑
- 避免重复执行：更新状态要和业务逻辑放在同一个事务里（DB）或用 Lua 脚本（Redis），否则可能写入成功但业务失败，下次又补
APScheduler 挂了之后怎么续上错过的 job
APScheduler 默认不保存 job 执行历史，MemoryJobStore 一崩全丢。想让它“记得”错过什么，得换存储 + 开启 misfire 处理。
- 改用
SQLAlchemyJobStore，并确保数据库连接稳定；jobstore配置里必须设coalesce=True，否则多个错失触发点会被合并成一次 - 每个 job 的
misfire_grace_time参数不能设太小（比如默认 1 秒），否则刚启动就发现“3 分钟前该跑的没跑”，直接丢弃；建议设为60（秒）以上 - 注意：
APScheduler不会回溯执行“所有错失的”，只执行“最近一次错失的”——它没有队列语义，别指望它补 10 次
用 Celery 做定时任务时，failed task 怎么自动重试
Celery 的 apply_async 支持重试，但定时任务（beat）发出去的 task 如果失败，默认不重试，除非显式配置。
- 在 task 函数上加装饰器参数：
@app.task(autoretry_for=(Exception,), retry_kwargs={'max_retries': 3, 'countdown': 60}) - 更稳妥的做法是：把定时触发逻辑和实际执行逻辑拆开，定时器只发一个“调度 task”，它再调用真正的业务函数，并自己捕获异常+记录失败；这样失败可进监控，也能人工干预
- 别依赖
retry处理数据库连接失败等临时问题——如果 broker（如 RabbitMQ）本身不可用，task 根本发不出去，重试也没用
本地开发时 schedule.run_pending() 不生效的常见原因
很多人写完 schedule.every().hour.do(job) 就以为万事大吉，结果发现 run_pending() 从不执行——根本原因是它只跑一次，不阻塞也不循环。
立即学习“Python免费学习笔记（深入）”；
- 必须手动加个死循环：
while True: schedule.run_pending(); time.sleep(1)，否则脚本执行完就退出 - 如果用了
threading启另一个线程跑这个循环，注意主线程别提前结束（比如没join），否则子线程被强杀 - Windows 下某些 IDE（如 PyCharm）调试时，
time.sleep()可能被中断，导致循环卡住；换成time.sleep(0.5)更稳
