不能直接用Django request-response流程生成耗时报表，因为会触发Nginx/Gunicorn超时、阻塞Web进程；必须用Celery+RabbitMQ异步执行，任务参数需序列化，前端轮询AsyncResult查状态，注意时区、内存和文件清理。
为什么不能直接用 Django 的 request-response 流程生成耗时报表
用户点击“导出年度销售报表”后，如果后端在 view 里直接执行 SQL、聚合、写 Excel、返回文件，很容易触发超时：Nginx 默认 60s，Gunicorn 默认 30s，浏览器也可能断连。更严重的是，多个请求会挤占 Web 进程，导致整个站点变慢甚至不可用。
- 耗时操作必须脱离 HTTP 请求生命周期
- 不是“加个
async def”就能解决——Django 同步视图无法 await 异步任务，且 Celery（常用搭配）本身不原生支持 async worker - RabbitMQ 在这里只做消息代理，真正执行任务的得是独立消费者进程（比如 Celery worker），不是 Django 主进程
怎么用 Celery + RabbitMQ 搭起可靠异步流水线
Celery 是最成熟的选择，它把 RabbitMQ 当作 broker，天然支持任务重试、优先级、定时、结果存储。别自己封装 AMQP 生产/消费逻辑——容易丢消息、没确认机制、难监控。
- 安装时明确指定 broker：
celery[redis]是常见误区，这里必须用celery[rabbitmq] -
CELERY_BROKER_URL配置格式要严格：amqp://guest:guest@localhost:5672//，末尾两个//表示默认 virtual host，漏掉会连错 - Django settings 里必须设置
CELERY_TASK_TRACK_STARTED = True，否则前端查不到任务是否已开始执行 - 任务函数不能依赖 Django 请求上下文（如
request.user），所有参数得序列化传入（user_id、report_type、date_range等）
示例任务定义（tasks.py）：
from celery import shared_task
from django.contrib.auth.models import User
import pandas as pd
<p>@shared_task(bind=True, max_retries=3)
def generate_sales_report(self, user_id, start_date, end_date):
try:
user = User.objects.get(id=user_id)</p><h1>执行查询、计算、生成 Excel 文件（存到 media/reports/）</h1><pre class='brush:python;toolbar:false;'> # ……
return {"status": "success", "file_path": "/media/reports/sales_2024.xlsx"}
except Exception as exc:
raise self.retry(exc=exc, countdown=60 * (2 ** self.request.retries))前端怎么知道报表“正在生成”还是“已就绪”
不能轮询数据库字段，也不能让前端等 WebSocket 推送（增加架构复杂度）。标准做法是：视图返回任务 ID，前端用这个 ID 轮询 Celery 的 AsyncResult。
- 触发任务的视图返回 JSON：
{"task_id": "3f8a1e…", "status": "submitted"} - 前端用
setInterval每 2–3 秒调用/api/task-status/?id=3f8a1e… - 后端视图用
AsyncResult(task_id).state查状态：PENDING、STARTED、SUCCESS、FAILURE - 成功时返回
{"status": "success", "download_url": "/media/reports/xxx.xlsx"}，注意download_url必须可被 Nginx 直接服务，不要走 Django view
关键细节：
-
AsyncResult默认不保存结果，需配置CELERY_RESULT_BACKEND（如rpc://或redis://） - 若用
rpc://，结果只保留一次，查完即丢；若需多次查，用 Redis 或数据库 backend - 不要返回原始数据（如 DataFrame），只返回路径或简要摘要，避免序列化开销和内存泄漏
大报表生成时最容易被忽略的三个坑
-
TIME_ZONE 不一致：Django 默认用 settings.TIME_ZONE，但 Celery worker 进程可能读系统时区，导致日期筛选错一天。务必在 celery.py 里显式设 timezone = 'Asia/Shanghai' 并开启 enable_utc = False
- 内存爆炸：Pandas 处理千万行数据时，
to_excel 可能吃光 worker 内存。改用 openpyxl 的 append() 模式，或分块写入，或导出为 CSV（用 StreamingHttpResponse 直接流式响应）
- 文件清理缺失：生成的临时 Excel 如果没人删，磁盘迟早爆。不要靠 crontab 定期扫，而是在任务成功后立即调用
os.remove()，失败时也应记录日志并告警，而不是静默留着
TIME_ZONE 不一致：Django 默认用 settings.TIME_ZONE，但 Celery worker 进程可能读系统时区，导致日期筛选错一天。务必在 celery.py 里显式设 timezone = 'Asia/Shanghai' 并开启 enable_utc = False to_excel 可能吃光 worker 内存。改用 openpyxl 的 append() 模式，或分块写入，或导出为 CSV（用 StreamingHttpResponse 直接流式响应） os.remove()，失败时也应记录日志并告警，而不是静默留着 RabbitMQ 本身不存报表数据，也不执行代码，它只管把“生成销售报表”这条消息，稳稳送到某个空闲的 Celery worker 手里——剩下的事，全看你怎么约束任务边界、控制资源、处理失败。
