不能直接传 Django ORM 对象给 Celery 任务，因 pickle 序列化会失败或导致数据过期；正确做法是只传主键 ID，Worker 中重新查询最新数据。
为什么不能直接把 Django ORM 对象传给 Celery 任务
因为 Celery 默认用 pickle 序列化参数，而 Django 的 Model 实例包含大量不可序列化的状态（比如数据库连接、缓存、_state 等）。一旦任务在 Worker 进程中反序列化，就会报 AttributeError: 'NoneType' object has no attribute 'connection' 或类似错误。
更隐蔽的问题是：即使侥幸序列化成功，Worker 拿到的也是“旧快照”，不是最新数据库状态；如果主进程修改了对象再发任务，Worker 仍会读到过期数据。
正确做法：只传主键 ID，Worker 中用 get() 重新查
这是最稳妥、最清晰的解耦方式。主键（通常是 id）是轻量、可序列化、无状态的标识符，Worker 只需用它发起一次 fresh 查询即可拿到当前最新数据。
- 任务函数签名必须只接收主键（如
user_id、order_id），不要带模型实例 - Worker 内部第一件事就是查库：
User.objects.get(id=user_id)—— 注意加异常处理 - 如果对象可能已被删除，用
get_object_or_404或捕获User.DoesNotExist - 批量场景下，别写循环查 N 次
get()，改用filter(id__in=[...])一次查出
Celery 任务里查 ORM 要注意数据库连接和事务
Celery Worker 默认不共享 Web 请求的数据库连接，但也不需要你手动管理连接——Django ORM 会自动从连接池取新连接。真正要小心的是事务：
立即学习“Python免费学习笔记（深入）”；
- Web 进程中 commit 后才发任务，否则 Worker 可能查不到刚写入的数据（尤其用 PostgreSQL 时）
- Worker 里的查询默认在自己的事务中，与 Web 请求无关；不要试图在任务里用
transaction.atomic包裹整个逻辑，除非你明确需要原子性写操作 - 如果任务要更新数据，建议用
select_for_update()防并发冲突，但得确保数据库支持（如 PostgreSQL/MySQL InnoDB）
进阶：用 django-celery-results 或自定义序列化器？没必要
有人想用 JSON 序列化 + 自定义字段还原对象，或引入 django-celery-results 存 ORM 状态——这些都增加复杂度且治标不治本。JSON 不支持 datetime、Decimal 等字段原生序列化；结果后端只是存返回值，不解决传参问题。
真正值得投入的是封装一层工具函数，比如：
@shared_task
def send_user_welcome_email(user_id):
try:
user = User.objects.get(id=user_id)
except User.DoesNotExist:
logger.warning("User %s not found in worker", user_id)
return
# 后续逻辑...
这种模式简单、可测、易 debug。唯一容易被忽略的点是：主键类型必须一致（UUIDField 要传字符串，BigAutoField 别传 float），否则 get() 直接抛 ValueError。
