Celery 的核心价值是将耗时操作异步化以避免阻塞主线程，关键在于确保任务可靠执行：需保证函数可序列化、参数用基础类型、加重试与超时机制、合理调度、路由分队列、完善错误处理与监控。
异步任务：让耗时操作不卡主线程
Celery 的核心价值在于把耗时操作（如发邮件、处理图片、调用外部 API）从 Web 请求中剥离出来，交由后台 worker 异步执行。关键不是“能不能跑”，而是“怎么确保它可靠地跑”。定义任务时加 @app.task 装饰器只是第一步；真正要注意的是：任务函数必须是**可序列化的**（不能含 lambda、闭包、未导出的类实例），参数尽量用基础类型（str/int/dict/list），避免传入数据库连接或 request 对象。
常见做法：
- 任务函数保持无状态，所有依赖通过参数传入（比如用户 ID 而不是 user 对象）
- 在任务内部重新获取所需数据（如用 ID 查库），而不是跨进程传递复杂对象
- 加 retry=True 并设 autoretry_for=(Exception,) 和 retry_kwargs={"max_retries": 3} 应对临时失败
- 用 soft_time_limit 防止任务无限卡住（比如网络请求没超时）
定时调度：不只是 crontab 的 Python 版本
Celery Beat 不是简单翻译 crontab 表达式，而是一个独立调度进程，负责按计划把任务发到消息队列。它的配置重点不在“什么时候触发”，而在“谁来触发”和“触发后怎么保障”。CELERY_BEAT_SCHEDULE 中每个条目需明确指定 task 名（字符串）、schedule（crontab 或 timedelta）、args/kwargs。注意：Beat 进程必须和 worker 同时运行，且两者共用同一套 broker 和 result backend。
实用建议：
立即学习“Python免费学习笔记（深入）”；
- 避免在 Beat 配置里写复杂逻辑，把判断逻辑放进任务函数内（例如“只在工作日发通知”应在任务里查 weekday，而非靠 crontab 模拟）
- 用 crontab(minute='*/5') 实现每 5 分钟一次，但注意秒级精度不支持（需改用 timedelta(seconds=300) + 自定义调度器）
- 上线前务必测试 celery -A proj beat --loglevel=info 是否能正常打印下一次调度时间
- 生产环境推荐用 django-celery-beat（Django 项目）或独立数据库表管理周期任务，便于动态增删
任务路由与优先级：让不同任务走不同的路
默认所有任务都发到同一个队列，容易造成低优任务（如日志归档）拖慢高优任务（如支付回调）。Celery 支持基于任务名、参数甚至运行时条件做路由。核心是三步：定义多个队列（如 high、default、low），配置 task_routes 映射规则，启动 worker 时用 -Q 指定监听队列。
典型配置方式：
- 按任务名路由：'send_email': {'queue': 'high'}
- 按模块路由：'myapp.tasks.*': {'queue': 'default'}
- 启动高优 worker：celery -A proj worker -Q high -c 4（4 个并发）
- 发送任务时指定队列：send_email.apply_async(args=[...], queue='high')
- 配合 priority 参数（需 broker 支持，如 RabbitMQ）进一步细化队列内顺序
错误处理与监控：别等报警才发现问题
任务失败不可怕，可怕的是失败后无声无息。Celery 提供了多层兜底机制：任务内 try/except 捕获业务异常、on_failure 回调记录上下文、task_revoked 信号响应取消动作、以及最终的 result.get() 主动拉取结果并抛异常。生产环境必须接入监控——至少做到失败自动告警、重试次数可视化、任务堆积趋势可查。
落地要点：
- 为每个任务设置 bind=True，可在函数内用 self.retry() 精确控制重试逻辑（如指数退避）
- 用 task_postrun 信号统一记录耗时、状态、返回值（脱敏后）
- 集成 Flower（pip install flower）提供实时 Web 界面，查看活跃任务、队列长度、worker 状态
- 将失败任务 ID 和 traceback 写入 ELK 或 Sentry，避免只依赖 Celery 日志滚动丢失
