根本原因是broker URL配置未生效或worker未加载正确配置模块，需确保Celery初始化时显式传入broker_url和result_backend，并用celery -A myapp.celery worker启动，同时验证Redis连接可达。
为什么直接用 celery worker 启动后任务不执行？
常见现象是调用 task.delay() 返回了 AsyncResult，但 Redis 里任务堆积、worker 日志无响应。根本原因通常是 broker URL 配置未生效或 worker 启动时未加载正确配置模块。
- 确保 Flask 应用中初始化 Celery 时显式传入
broker_url和result_backend，不要依赖环境变量自动推导 - 启动 worker 必须指定应用模块路径，例如：
celery -A myapp.celery worker --loglevel=info，其中myapp.celery是 Python 可导入的 Celery 实例对象路径 - 检查 Redis 连接是否可达：在 Python shell 中运行
import redis; r = redis.Redis(); r.ping()，避免因网络或认证失败导致静默降级
Flask 上下文丢失：为什么 current_app 在 Celery 任务里是 RuntimeError？
Celery 任务运行在独立进程/线程中，不继承 Flask 的请求上下文，current_app 和 g 均不可用。这不是 bug，而是设计使然。
- 不要在任务函数体内直接使用
current_app.config或db.session；改用显式传参，例如：send_email.delay(user_id=123, template_name="welcome") - 如需复用 Flask 初始化的扩展（如 SQLAlchemy），应在任务函数内重新构造实例，或通过工厂函数注入——推荐将 DB 操作封装为纯函数，接收必要参数而非依赖全局对象
- 若必须访问配置，可在任务启动前从 Flask app 提取并序列化传入，例如：
CELERY_BROKER_URL = current_app.config["CELERY_BROKER_URL"]提前读出，作为参数传给任务
apply_async 和 delay 的实际区别在哪？
两者都用于发送任务，但行为差异影响调试和可靠性。
-
delay()是apply_async()的语法糖，等价于apply_async(args=[], kwargs={})，仅支持位置/关键字参数，无法设置重试、超时、路由等高级选项 - 生产环境建议统一用
apply_async()：可加countdown=60延迟执行，max_retries=3控制重试，queue="high_priority"指定队列，这些在delay()中无法表达 - 注意
apply_async()返回的是AsyncResult对象，不是任务结果；要获取结果需调用.get(timeout=10)，且前提是启用了result_backend
Redis 内存暴涨、任务积压后如何安全清理？
开发时频繁重启 worker 或误发无限循环任务，会导致 Redis 中堆积大量未确认（unacked）消息和过期 result，占用内存且干扰监控。
- 清空所有队列（谨慎！）：
redis-cli KEYS "celery*" | xargs redis-cli DEL，但会丢弃正在处理中的任务 - 只清空待消费任务：
celery -A myapp.celery purge，它只删除各队列的 pending 消息，不影响已开始执行的任务状态 - 定期清理 result backend 中的过期记录：Celery 默认不自动清理，需手动配置
result_expires=3600（单位秒），或用celery -A myapp.celery control cancel_consumer queue_name停止消费后再删键
真正麻烦的是带复杂依赖的任务链（chord、group）失败后残留的状态，这种场景下别指望一键清理，得结合日志定位具体 task_id，再针对性删 Redis key。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
