celery beat 仅调度不执行，需配合 worker 才能消费任务；常见问题包括 broker 地址不一致、flask 中 celery 实例非全局、rabbitmq x-delay 插件未启用、redis 死信延迟不可控、apscheduler 不支持分布式、while true 存在健壮性缺陷。
用 Celery Beat 做定时任务，为什么消息没发出去？
因为 celery beat 只负责“发令”，不负责“执行”——它把定时任务塞进 broker（比如 Redis），但如果没有运行 worker，这些任务就永远卡在队列里，不会被消费。
-
celery -A tasks beat --loglevel=info启动的是调度器，只打印 “Scheduler started”；必须另开终端运行celery -A tasks worker --loglevel=info，才能真正干活 - 常见错误现象：
beat日志显示 “Sent task xxx”，但worker日志完全没反应 → 检查broker地址是否一致（比如一个连redis://localhost:6379/0，另一个连/1） - 如果用
Flask集成，别把celery = Celery(...)写在路由函数里——实例必须全局唯一，否则beat和worker加载的不是同一个配置
延迟消息该选 RabbitMQ x-delay 还是 Redis + 死信队列？
RabbitMQ 的 x-delay 插件看着方便，但生产环境慎用：它依赖插件启用、不支持消息重试、延迟精度在秒级且不可控；而 Redis 本身不原生支持延迟，得靠死信队列模拟，但更可控、可监控、易排查。
- RabbitMQ
x-delay要求服务端已启用rabbitmq_delayed_message_exchange插件，Docker 部署时容易漏掉这步，导致ChannelClosed错误 - Redis 死信方案本质是“TTL + 过期转发”：给消息设
expire，过期后自动入死信队列；但要注意，Redis 的 key 过期是被动清理，高并发下可能延迟数秒才触发，不适合要求严格准时的场景（如支付超时关单） - 参数差异：
x-delay是 header 传毫秒数（"x-delay": 5000）；死信方案得自己算好 TTL，并绑定好dead-letter-exchange和 routing key，配置项多但逻辑透明
APScheduler 跟 Celery 定时，到底该用哪个？
单机小项目用 APScheduler，只要不重启进程，它就能一直跑；但一旦服务扩容、部署多实例，或需要任务失败重试、跨机器协同，就必须切到 Celery —— APScheduler 的内存型 jobstore 天然不支持分布式。
-
APScheduler的BackgroundScheduler在 Flask/FastAPI 中启动后，若框架热重载（如--reload），会启两份 scheduler，导致任务重复执行；必须加判断if not scheduler.running: -
Celery的beat_schedule支持 Cron 表达式（'schedule': '0 9 * * 1-5'），也支持浮点秒级（'schedule': 3.5），但注意：浮点值在集群中可能因时钟漂移造成执行时间抖动 - 性能影响：
APScheduler单进程扛不住每秒上百个定时任务；Celery可横向扩worker，但beat必须单点运行，否则任务会发两遍——得用锁（如 Redis 分布式锁）或部署时确保仅一个beat实例
Python 里写 while True + sleep，真不能用？
能用，但只限于开发调试、脚本工具、或生命周期极短的离线任务；一旦放进 Web 服务或长期运行的后台进程，它就成了隐患：无法优雅退出、不响应信号、OOM 风险高、日志打满磁盘。
立即学习“Python免费学习笔记（深入）”；
- 常见错误现象：用
while True: do_something(); time.sleep(60)做心跳上报，结果某次do_something()报错未捕获，整个循环崩掉，后续再无心跳 - 替代方案很简单：加
try/except+time.sleep()固定间隔，比裸循环靠谱得多；但更推荐用schedule库——它内部也是sleep，但封装了任务管理、异常抑制、运行统计 - 别忽略时区问题：
time.sleep(60)是系统本地时间，如果服务器时区设错，配合 cron 或人工干预时间，会导致任务漂移；关键业务务必用datetime.now(timezone.utc)对齐
混合架构最麻烦的从来不是怎么搭，而是“谁负责超时、谁管重试、谁记日志、谁清失败任务”——这些边界不划清，消息和定时就会互相甩锅。
