task.delay()未触发的根本原因是Celery实例未连上Broker，常见于broker_url配置错误或Redis服务不可用，启动时需确认日志首行显示“Connected to redis://...”。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
为什么 task.delay() 没触发，但日志里没报错
常见现象是调用 task.delay() 后任务石沉大海，Worker 日志安静如鸡，连 Received task 都不出现。根本原因往往不是代码写错了，而是 Celery 实例没连上 Broker，或者 Broker 地址配置错位了。
-
broker_url必须在 Worker 启动前就生效，不能靠运行时改环境变量“临时补救” - Redis 地址写成
redis://localhost:6379/0时，如果本地没 Redis 或端口被占，Celery 默认静默失败——加broker_transport_options = {'visibility_timeout': 3600}不解决连接问题，只影响已入队任务的超时逻辑 - 用
celery -A myapp worker --loglevel=info启动时，第一行必须看到Connected to redis://...，否则立刻检查broker_url和网络连通性（比如redis-cli -u redis://localhost:6379 ping）
如何让 @shared_task 正确识别并执行
@shared_task 看似省事，实际依赖模块导入路径和 CELERY_IMPORTS（旧版）或 include 配置（新版）。它不会自动扫描整个项目，只认你明确告诉它的位置。
- 如果任务定义在
myapp/tasks.py，Worker 启动命令必须是celery -A myapp worker，而不是celery -A tasks worker——-A后面是 Python 包名，不是文件名 -
@shared_task的函数必须能被 import：确保myapp/__init__.py存在，且tasks.py里没有未处理的ImportError（比如误用了 Django 模型但没配置DJANGO_SETTINGS_MODULE） - 任务名默认为
module_name.function_name，若手动指定name='myapp.send_email'，则调用时必须用这个字符串，不能只写send_email.delay()
异步任务里调 Django ORM 报 django.core.exceptions.AppRegistryNotReady
这是 Celery + Django 最典型的环境错配：Worker 进程启动时没加载 Django 配置，导致 ORM 尚未初始化。
- 必须在 Celery 实例创建前触发 Django 初始化：
import os os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'myproject.settings') import django django.setup() # 这行不能少，也不能晚于 Celery 实例化 - 不要在任务函数内部做
django.setup()——每个任务都执行一次会崩，且线程不安全 - 使用
django-celery-beat或自定义定时任务时，同样要确保其模块导入链中已触发django.setup()
任务重试后参数变 None 或类型错乱
Celery 默认用 pickle 序列化参数，而 pickle 对跨进程、跨版本、带 lambda/嵌套类的对象极不友好。重试时反序列化失败，可能静默降级为 None 或抛出 TypeError。
立即学习“Python免费学习笔记（深入）”；
- 强制改用 JSON 序列化：
task_serializer = 'json'、result_serializer = 'json'、accept_content = ['json']，但代价是只能传 dict/list/str/int/bool/None - 避免传 Django model 实例（哪怕只传
.id也比传整个对象安全）、函数、文件句柄、数据库连接等不可序列化对象 - 重试逻辑写在任务内（
raise self.retry(exc=exc, countdown=60)）比靠 Broker 重发更可控，因为你能显式控制参数是否重载
Django 项目里用 Celery 最容易被忽略的，是 Worker 进程生命周期和 Django 配置的耦合点——它不像 Web 请求那样有中间件兜底，一旦初始化漏掉，后续所有 ORM、缓存、信号都会无声失效。
