根本解法是避免直接传大体积参数，只传最小必要标识符（如id、uuid、s3 key），任务内重新查询或下载；大文件必须存外部存储，批量任务需分页调度，重试机制要求参数轻量化。
直接传大体积参数（比如整个模型实例、长文本、二进制数据）进 Celery 任务，会导致序列化开销剧增、Broker 压力升高、任务入队变慢，甚至触发 Redis 内存淘汰或 RabbitMQ 拒绝连接。根本解法不是压缩或调优序列化，而是避免传递。
为什么不能直接传 model_instance 或大字典？
Celery 默认用 JSON 序列化（CELERY_TASK_SERIALIZER='json'），而 Django 模型对象无法直接 JSON 序列化；强行传会报 Object of type Model is not JSON serializable。即使改用 pickle，也会把整个对象及其关联字段、缓存状态一并打包，可能达 MB 级——这会让 Redis 内存暴涨，且反序列化耗时翻倍。
delay() 传参前必须做 ID 提取和惰性加载
所有需要在任务中访问的数据，只传最小必要标识符（如主键 id、uuid），并在任务内部重新查询。这不是绕路，是唯一可控的方式。
python-docx Skill功能概述python-docx Skill是一项面向实际任务的技能，主要用于本Skill提供使用python-docx生成专业Word文档的标准方法和最佳实践；生成安全服务方案文档；核心要点生成技术架构设计文档；生成任何需要专业排版的Word文档；核心库 : python-docx；使用与执行辅助库 : docx.shared , docx.enum , docx.oxml.ns；标准代码模板；1. 文档初始化；2. 字体设置（必须！它将相关步骤、工具调用和结果整理方式集
- ❌ 错误写法：
send_report.delay(user=user_obj, data=big_dict) - ✅ 正确写法：
send_report.delay(user_id=user_obj.id, report_id=report.id) - 任务函数内立刻执行：
user = User.objects.get(id=user_id)（注意加.only()或.values()限制字段） - 若需跨库或非 Django 模型，改用稳定标识符（如 S3 key、外部系统订单号）+ 封装查询逻辑
大文件/二进制内容必须走外部存储，不走 Broker
上传的 PDF、图片、日志压缩包等，绝不可塞进 delay() 参数。它们应先存到可靠外部介质（S3、MinIO、本地共享路径），再把路径或 URL 传给任务。
- 上传完成后，Django 视图中生成唯一 key（如
f"report_{uuid4().hex}"），存入 S3，并记录元数据到数据库 - 调用：
process_pdf.delay(s3_key=s3_key, mime_type="application/pdf") - Worker 任务中用 boto3 或 requests 下载，处理完删临时副本（或设生命周期策略）
- Redis 中只存几十字节的 key，而非几 MB 的 raw content
批量任务别用 group() 塞几百个大参数
group() 会把全部子任务参数一次性序列化进一个消息体，极易超限。遇到“给 500 个用户发定制邮件”这类场景，必须拆成原子粒度 + 分页调度。
- 不要：
group(send_email.s(user=u, template_data=rendered) for u in users) - 要：
for user_batch in chunked(users, 20): send_batch_emails.delay(user_ids=[u.id for u in user_batch], template_id=123) - 在
send_batch_emails内部用User.objects.in_bulk(user_ids)一次查出全部用户，避免 N+1 - 如果 batch 太大导致单任务执行超时，再加
max_retries=2和指数退避
真正容易被忽略的是：任务重试机制会重复序列化同一份大参数。哪怕第一次失败只是网络抖动，第二次重试仍会把原始大 payload 再压一遍 Broker。所以“只传 ID + 外部存大内容”不是最佳实践，而是底线要求。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
