先确认现象：任务没执行还是执行了没结果

排查Celery配置问题，第一步不是翻文档，而是确认你观察到的现象是什么。最常见的情况有两种：任务根本没被worker消费，或者任务执行了但视图里拿不到结果。两种现象的排查路径完全不同，第一步走错会多花很多时间。

我会先在Django视图中用task.delay()触发一个简单任务（比如打印日志或写入数据库），然后看worker终端有没有输出。如果worker没有反应，问题出在broker连接或任务发现上；如果worker有输出但视图拿不到结果，问题出在结果后端或任务函数本身。

容易误判的地方：安装和配置细节

很多人卡在第一关——配置不完整。下面这段是必需的初始化步骤，我直接贴过来，因为它覆盖了最容易忽略的点：

在Django项目中集成Celery，首先需要安装celery和相应的消息代理库，如redis或rabbitmq。确保在项目的settings.py中添加CELERY_BROKER_URL配置项，指定代理地址，例如'redis://localhost:6379/0'。同时，需要在项目同名模块的__init__.py中导入Celery实例，并调用app.autodiscover_tasks()来自动发现所有已注册的应用中的tasks模块。注意：如果使用RabbitMQ，需确保服务已启动且端口正确；若使用Redis，建议为Celery使用单独的数据库编号，避免与缓存数据冲突。

我遇到过的误判包括：忘记在__init__.py中调用app.autodiscover_tasks()，导致任务函数始终找不到；或者Redis用到了与缓存相同的数据库编号（比如0），最后缓存清空时任务也跟着丢失。建议先确认settings.py中是否同时存在CELERY_BROKER_URL和CELERY_RESULT_BACKEND（如果不需要结果可以省略后者，但大多数场景都需要）。

Broker选择：根据任务丢失容忍度决定

消息代理是整个队列的基石，选错会导致后续反复返工。关于Redis和RabbitMQ的取舍，下面是成熟的经验：

消息代理的选择直接影响任务队列的可靠性与性能。Redis配置简单、延迟低，适合大多数中小型项目，但不保证消息不丢失（即使是持久化模式也有极小概率）。RabbitMQ提供完整的AMQP协议，支持消息确认、死信队列等高级特性，更适合对可靠性要求高的场景。判断依据：如果任务丢失可接受，选Redis；如果任务必须精确执行一次，选RabbitMQ。注意：生产环境中避免使用SQLite或内存型broker（如Django默认的数据库队列），它们会显著拖慢性能且易导致死锁。

我个人的倾向是：对于新项目，如果团队没有RabbitMQ运维经验，先用Redis跑起来，等到出现消息丢失问题时再迁移。迁移成本不高，因为Celery的broker切换只需要改CELERY_BROKER_URL这一行配置。但初期不要用数据库或内存作为broker，那不是“简化”，而是埋坑。

任务定义：函数参数和重试逻辑

任务函数写不好，调试时非常痛苦。下面这段指出了最常见的两个错误：

在Django应用的tasks.py文件中定义任务时，需使用@app.task装饰器。任务函数应接收可序列化的参数（如基本类型、JSON兼容结构），避免传递Django模型对象；如需操作数据库，应在任务内部通过模型ID重新查询。常见坑：忘记设置bind=True导致无法访问任务实例（如重试或日志），或未定义失败重试逻辑。建议在装饰器中添加autoretry_for参数指定重试的异常类型，并设置max_retries限制重试次数，防止无限重试耗尽资源。

检查任务是否可序列化：在视图里先手动构造参数传入task.delay()，如果抛出Object of type X is not JSON serializable，就把参数换成基础类型。另外，如果任务需要访问当前请求的用户或request对象，一定要把user.id传进去，不要在任务内部依赖全局变量。重试逻辑建议从简单开始：只在捕获到网络或数据库连接异常时重试，业务逻辑异常（如参数错误）不需要重试，否则会无限循环。

启动Worker：命令与守护进程

确认配置和任务定义无误后，启动worker。如果本地开发，直接在项目根目录执行：

celery -A your_project_name worker -l info --concurrency=4

注意--concurrency参数：不指定的话默认是CPU核心数，但许多任务涉及I/O等待，设置4或8通常够用。显式指定队列名称：-Q default,email,reports，否则所有任务都进入默认队列。生产环境建议用supervisor管理worker进程，配置日志轮转并监控内存。如果发现worker启动后收不到任务，先用celery -A proj inspect active查看是否有任务在跑，再用celery -A proj inspect registered确认任务是否注册成功。

验证方法：从日志到结果检查

配置完成后，用一组小任务完成全链路验证：1）触发一个不依赖数据库的任务（如打印时间戳），观察worker日志是否有Received task和Task succeeded；2）检查结果后端，用AsyncResult(task_id).state确认状态。如果任务状态一直PENDING，最可能的原因是worker没有消费该队列，或者路由冲突。检查broker连接：redis-cli ping或rabbitmqctl list_queues。如果任务立刻SUCCESS但实际没做任何事，检查任务函数有没有被正确导入（可以在tasks.py里临时加个print语句）。

回滚风险点：修改broker URL或序列化配置时，注意正在排队的任务可能因为参数格式不兼容而失败。建议先在测试环境验证，生产环境切换broker时最好清空旧队列。后续维护只需留意worker的内存增长和broker的持久化设置，不需要频繁调优。