Django异步视图需全链路异步支持，但WSGI模式下仍阻塞；耗时接口应拆分为“发任务+查状态”，优先用Celery而非直连RabbitMQ；前端采用长轮询，配合缓存与Nginx超时调优。
为什么不能直接用 Django 的 async/await 处理耗时接口
Django 从 3.1 开始支持 async 视图，但前提是整个请求链路（ASGI server、中间件、数据库驱动）都得是异步的。现实中，多数项目仍跑在 WSGI 模式下，sync_to_async 包裹 ORM 操作会阻塞事件循环；更关键的是，哪怕视图异步了，HTTP 连接仍需等待结果返回——用户浏览器卡着不动，和“异步”毫无关系。
真正要解的不是“Python 怎么不卡”，而是“用户要不要等”。所以耗时接口异步化，本质是：把执行拆出去，让 HTTP 接口只负责“发任务 + 查状态”。
用 RabbitMQ 发任务前，先确认 Celery 是不是更合适
RabbitMQ 是消息中间件，不是任务调度器。你得自己写生产者、消费者、重试逻辑、失败监控、结果存储……而 Celery 就是为这事设计的，它默认支持 RabbitMQ（或 Redis）作 broker，且封装了：apply_async、get()、revoke()、retry() 等关键能力。
除非你有强定制需求（比如跨语言消费、精细控制消息 TTL、与现有 AMQP 生态深度集成），否则别绕过 Celery 直连 RabbitMQ。
立即学习“Python免费学习笔记（深入）”；
-
CELERY_BROKER_URL = 'amqp://guest:guest@localhost:5672//'—— 配在settings.py即可 - 任务函数加
@shared_task装饰器，调用时用my_task.delay(arg1, arg2)或my_task.apply_async(args=[...], countdown=60) - 别在任务里直接操作 request 或 session —— 它们不在 HTTP 上下文中
- 数据库连接需显式关闭或用
db.close_old_connections()，尤其长周期任务
前端怎么不傻等？用长轮询而非 WebSocket
WebSocket 对后端压力大、Nginx 配置复杂、移动端兼容性差。长轮询（Long Polling）更轻量：前端发一个 GET 请求，后端不急着返回，等任务完成才回 JSON；前端收到响应后立刻再发下一个请求。体验接近实时，实现却简单。
关键点在于后端不能超时断连：
- Django 视图里用
cache.get_or_set('task_result_123', lambda: None, timeout=300)存结果，避免重复查 DB - Nginx 需调大超时：
proxy_read_timeout 300;（默认 60 秒，不够） - 前端 fetch 要设
signal并 abort 旧请求，防止并发堆积 - 别用
time.sleep(1)轮询 cache —— 改用while not result and time.time() + <code>time.sleep(0.5)
任务 ID 怎么传、怎么查、怎么防乱
用户触发耗时操作时，后端必须立刻返回一个唯一 task_id（推荐 UUID4），而不是等任务跑完再给。这个 ID 要贯穿全流程：前端轮询地址带它、任务函数存结果用它、缓存 key 也基于它。
容易漏的细节：
- 不要用自增 ID 当 task_id —— 易被枚举、暴露数据量
- 缓存结果时，加个前缀如
task_result:{uuid}，避免和业务 key 冲突 - 任务失败时，也要写入缓存：
cache.set(f'task_result:{tid}', {'status': 'failed', 'error': str(e)}, timeout=3600) - 前端轮询接口要校验
task_id格式（正则^[0-9a-f]{8}-[0-9a-f]{4}-4[0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$），防恶意扫描
最常被忽略的是清理机制：成功结果缓存 5 分钟够了，失败结果缓存 1 小时也够了，别让它永久躺在 Redis 里。可以靠 cache 的 TTL 自动淘汰，别额外写定时任务扫库。
