Celery worker报NotRegistered错误是因为任务模块未被自动导入或autodiscover_tasks路径配置错误；apply_async卡住多因broker连接失败或序列化配置不当；定时任务重复执行源于beat多实例或缺乏幂等控制；AsyncResult.get()超时或返回None是result_backend未配置或过期策略过严所致。
为什么直接用 celery 启动 worker 会报 NotRegistered 错误
任务没被发现，不是代码写错了，而是 Celery 实例找不到你定义的函数。常见原因是：任务模块没被 celery 自动导入，或者 app.autodiscover_tasks() 路径配置错。
实操建议：
- 确保任务函数用
@app.task装饰（不是@shared_task，除非你明确用了shared_task实例） -
celery -A myproject.celery_app worker --loglevel=info中的myproject.celery_app必须指向含Celery()实例的 Python 模块，且该模块能被 Python 正确 import - 如果任务分散在多个文件，用
app.autodiscover_tasks(['myapp.tasks', 'utils.jobs'])显式列出包路径，别依赖默认的['tasks'] - Django 项目中，
autodiscover_tasks()通常放在__init__.py或celery.py末尾，且要确保 Django settings 已加载（加os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'myproject.settings')）
怎么让 apply_async 真正异步执行，而不是卡住等结果
apply_async 本身不阻塞，但如果你紧接着调用 .get()，就退化成同步了。更隐蔽的问题是 broker 连接失败或序列化配置错，导致任务根本没发出去，看起来像“卡住”。
实操建议：
- 确认 broker URL 正确：
redis://localhost:6379/0或amqp://guest@localhost//，注意末尾斜杠数量（RabbitMQ 需两个//） - 检查
task_serializer和result_serializer是否设为'json'；若用了'pickle'，worker 和 producer Python 版本不一致会静默失败 - 发任务时加
throw=False参数：例如my_task.apply_async(args=[1,2], throw=False)，避免异常直接抛出掩盖底层问题 - 用
celery -A xxx inspect active查看当前活跃任务，确认任务是否真的进队列
如何用 crontab 或 timedelta 做定时调度，又不引发重复执行
Celery Beat 是独立进程，它只负责按 schedule 发送任务，不保证任务不重复——重复根源通常是：多个 beat 实例、任务未设置唯一 ID、或数据库幂等逻辑缺失。
实操建议：
- 定时任务必须显式指定
name：例如@app.task(name='myapp.tasks.cleanup_old_logs')，否则 beat 无法识别同一任务多次注册 - 用
crontab(minute='*/5')表示每 5 分钟，但注意hour='*'和hour='0-23'行为不同；测试阶段先用timedelta(seconds=10)快速验证 - Beat 启动命令加
--scheduler celery.beat:PersistentScheduler并配schedule_filename='/var/run/celerybeat-schedule'，避免重启后丢失调度状态 - 关键业务任务内部加数据库锁或 Redis SETNX 判断，别只靠 Celery 的
once插件——它不解决跨 worker 竞态
为什么 AsyncResult.get() 老是超时或返回 None
不是代码问题，是 result backend 没配对或过期策略太激进。Celery 默认不保存结果，get() 就只能等或返回空。
实操建议：
- 必须显式配置
result_backend，比如redis://localhost:6379/1（和 broker 分开 DB），不能只写broker_url - 设
result_expires=3600（秒），否则 Redis backend 默认只存 1 小时，超时后get()返回None - 调用
get(timeout=10)时，timeout 是等待结果的最长时间，不是任务执行上限；任务本身超时要用soft_time_limit/time_limit - 生产环境慎用
get()，前端轮询推荐用async_result.state查状态，或用 Redis Pub/Sub 主动推送完成事件
真正麻烦的从来不是怎么写一个 @task，而是 broker 连不上时日志里没报错、beat 进程挂了没人告警、或者 result backend 的 TTL 和业务预期对不上——这些点没盯住，任务队列就从加速器变成黑盒延迟源。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
