不能用同步视图等 Celery 任务完成，因为 Django 视图同步阻塞，调用 result.get() 会耗尽工作进程、引发请求堆积和 504 错误，违背异步解耦设计；应返回 202 + 任务 ID，由前端轮询或 WebSocket 获取结果。
直接返回 202 Accepted + 唯一任务 ID，前端轮询或 WebSocket 监听结果。不要让请求卡在 Django 主线程里等 Celery 执行完。
为什么不能用同步视图等 Celery 任务完成
Django 视图是同步阻塞的，一旦调用 task.delay() 后立刻返回，但如果你紧接着写 result.get(timeout=60)，就等于把 Web 请求拖进一个长等待——这会吃光 Gunicorn/UWSGI 工作进程，导致其他请求排队甚至超时。
常见错误现象：
- 接口响应时间忽高忽低，偶发 504 Gateway Timeout
- 并发稍高时服务器 CPU 不高但请求堆积，
netstat -an | grep :8000 | wc -l显示大量 ESTABLISHED 连接 - Celery worker 日志显示任务已成功，但 Django 接口迟迟不返回
根本原因：Django 和 Celery 是两个独立生命周期的进程，强行同步等待违背了异步解耦的设计初衷。
Django 视图只负责“派发”和“查状态”
一个标准流程分三步：提交任务 → 返回任务 ID → 前端按 ID 查询结果。Django 只做前两步，第三步是纯读操作，轻量且可缓存。
实操建议：
- 用
uuid.uuid4().hex或django.core.signing.Signer().sign(time.time())生成客户端可携带的、不可预测的任务标识，避免被枚举 - 把任务 ID 存进数据库（如
TaskResult模型），字段至少含：task_id、status（PENDING/STARTED/SUCCESS/FAILURE）、result（JSONField 或 Text）、created_at - 视图返回时加
Cache-Control: no-cache，防止代理或浏览器缓存 202 响应 - 不要在视图里调用
AsyncResult(task_id).get()—— 这仍会阻塞；只用AsyncResult(task_id).state查状态（它走的是 Redis/Broker，极快）
前端怎么安全轮询结果而不炸服务
轮询本身没问题，但乱设频率或不加退出条件就是事故源头。关键不是“要不要轮询”，而是“怎么轮得克制”。
推荐做法：
- 首次返回后，前端立即发起第一次查询（
/api/task-status/?id=abc123），间隔从 500ms 起步 - 每次收到
PENDING或STARTED，下一次间隔 ×1.5（指数退避），上限封顶到 10s - 连续 3 次收到
FAILURE或超时（比如总耗时 > 5min），前端主动终止轮询并提示用户“任务执行失败，请重试” - 后端接口必须对
id做存在性校验和权限检查（比如只允许创建者查自己的任务），否则暴露任意任务状态是严重安全风险
示例响应体（JSON）：
{"id": "abc123", "status": "SUCCESS", "result": {"summary": "xxx"}, "created_at": "2026-04-13T04:22:10Z"}
Celery 任务完成后怎么更新状态又不拖慢 worker
很多人在 @shared_task 函数末尾直接写 TaskResult.objects.filter(id=...).update(...)，这看似简单，但在高并发下会引发数据库连接争抢和事务锁表。
更稳的方式：
- 任务函数只做核心逻辑，成功后 return 结果 dict（别太大，
- 用
task.after_return钩子或signals.task_success信号，在单独线程/进程里更新 DB 状态 —— 这样主 worker 不卡 - 或者更轻量：把结果写进 Redis 的 hash（
task:abc123），Django 查状态时优先读 Redis，没命中再查 DB 并回填 - 记得给 Redis key 设 TTL（比如 1 小时），避免垃圾数据堆积
容易被忽略的一点：Celery 默认不保证任务执行顺序，如果任务间有依赖，要用 chord 或显式链式调用（task1.s() | task2.s()），而不是靠时间先后猜测。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
