CELERY_BROKER_URL必须指向Redis且与CELERY_RESULT_BACKEND分用不同数据库编号，推荐broker用db=0、backend用db=1；须先验证Redis服务运行、端口连通及密码正确性，再配置Celery。
CELERY_BROKER_URL 必须指向 Redis 实例，且不能和 CELERY_RESULT_BACKEND 共用同一数据库编号（尤其在生产环境），否则任务状态可能被意外覆盖或清空。
确认 Redis 连接可用再配 Celery
很多「配置完跑不起来」的问题，根源其实是 redis 根本没连上。别急着写 celery.py，先手动验证：
- 确保 Redis 服务已启动：
redis-server.exe（Windows）或redis-server（Linux/macOS） - 用
redis-cli ping测试连通性，返回PONG才算通过 - 如果用 Docker，检查容器是否 expose 6379 端口、网络是否互通（比如
docker network inspect） - Django 项目里临时加一行测试代码：
import redis; r = redis.Redis(host='localhost', port=6379, db=0); r.ping()
，避免环境变量或 DNS 解析干扰
CELERY_BROKER_URL 和 CELERY_RESULT_BACKEND 的 db 编号要分开
Redis 的每个 database 是隔离的逻辑空间（db=0 到 db=15）。Celery 默认把 broker 和 result 存到同一个 db，容易互相污染：
- 推荐写法：
CELERY_BROKER_URL = 'redis://localhost:6379/0'（仅存任务队列） -
CELERY_RESULT_BACKEND = 'redis://localhost:6379/1'（单独存执行结果） - 若用密码，格式是
redis://:your_password@localhost:6379/0，注意冒号位置 - Windows 下若用
127.0.0.1替代localhost，可绕过 IPv6 解析延迟问题
celery.py 中 autodiscover_tasks 的参数决定任务发现范围
任务文件（如 myapp/tasks.py）能否被自动加载，取决于 autodiscover_tasks 的调用方式：
- 最稳妥写法：
app.autodiscover_tasks(lambda: settings.INSTALLED_APPS)—— 只扫已注册的 app - 如果任务分散在非 app 目录（如
core/tasks.py），得显式传路径：app.autodiscover_tasks(['core', 'utils']) - 别漏掉
__init__.py：每个含tasks.py的目录必须有该文件，否则 import 失败 - 任务函数必须用
@shared_task或@app.task装饰，裸函数不会被识别
启动 worker 时 -A 参数必须匹配实际模块路径
错误的模块路径会导致 ImportError: No module named 'xxx'：
- 假设项目结构是
myproject/myproject/celery.py，那么启动命令是：celery -A myproject.celery worker --loglevel=info - 不是
-A myproject，也不是-A myproject.celery.py（后缀不能写） - Windows 上建议加
--pool=solo参数，避免 multiprocessing 模块的 fork 问题 - 开发时用
--loglevel=debug查看任务入队/出队日志，比只看INFO更易定位卡点
maxmemory 策略和 eviction 行为。一旦任务结果堆积、内存满，Redis 可能静默丢弃 key，导致 AsyncResult.get() 返回 None 或超时——这问题不会报错，只会让任务「看起来成功但拿不到结果」。 
