当某个动作必须「无论从哪条路径创建/修改模型」都触发时，才该用post_save而非视图逻辑，如用户注册后发邮件、订单支付后扣库存；它确保逻辑与请求入口（admin/api/命令）无关，避免重复、遗漏或测试困难。
什么时候该用 post_save 而不是直接写在视图里？
当某个动作必须「无论从哪条路径创建/修改模型」都触发时，post_save 才是合理选择。比如用户注册成功后发欢迎邮件、订单状态变「已支付」后扣减库存——这些逻辑和请求入口（Django Admin、API View、管理命令）无关，硬塞进视图会导致重复、遗漏或测试困难。
常见错误是把本该通用的副作用（如日志记录、缓存失效）写死在 APIView 的 perform_create 里，结果后台用 manage.py loaddata 导入数据时信号不触发，业务状态就脱节了。
实操建议：
安全 Python 代码沙箱：在隔离的沙箱中执行任意 Python 代码，预装 requests、NumPy、pandas 库。返回 stdout、stderr。
- 只对「模型层确定性事件」用
post_save，比如created=True时初始化关联对象 - 避免在信号里做耗时操作（如 HTTP 请求、复杂计算），改用 Celery 异步任务封装
- 信号接收器函数必须加
@receiver(post_save, sender=MyModel)，且确保模块被 Django 自动发现（通常放在apps.py或显式导入）
disconnect 为什么总被忽略？
Django 不会自动清理已注册的信号监听器，测试时反复导入模块、重载应用会导致同一信号被绑定多次，一次模型保存可能触发 3 次邮件发送——这种 bug 在本地难复现，上线后突然暴增告警。
实操建议：
- 在测试用例 setUp 中用
my_signal.disconnect(receiver=my_handler, sender=MyModel)显式断开 - 生产环境若需动态开关信号（如数据迁移期间禁用通知），用全局 flag 控制接收器内部逻辑，而不是反复
connect/disconnect - 检查是否误将信号注册写在函数体内部（每次调用都重新注册），应放在模块顶层
为什么 pre_delete 拿不到外键关联对象？
因为 Django 在执行 DELETE SQL 前就触发 pre_delete，此时关联对象可能已被数据库级联删除（取决于 on_delete 设置），或尚未加载到内存。比如 OrderItem 的 pre_delete 里访问 self.order.user.email，大概率抛 DoesNotExist。
实操建议：
- 需要关联数据时，提前在
post_init或__init__中缓存关键字段（如self._cached_order_user_id = self.order.user_id） - 改用
post_delete：虽然对象已删，但信号参数里还保留原始实例（未刷新的 ORM 对象），可读取instance.id、instance.name等已知字段 - 涉及级联删除场景，优先考虑数据库触发器或事务钩子，而非依赖 Django 信号顺序
Signals 和事务边界怎么配合？
post_save 在事务提交前触发，如果信号里抛异常，整个事务会回滚——这看似安全，但容易掩盖真实问题。比如缓存更新失败导致订单创建失败，用户看到的是「服务器错误」而非「库存不足」。
实操建议：
- 默认用
transaction.on_commit(lambda: my_task.delay())包裹异步操作，确保只在事务成功后执行 - 同步操作（如写本地日志）允许失败，但要在接收器里
try/except捕获并记录错误，不能让信号中断主流程 - 避免在信号中开启新事务（
atomic嵌套），Django 1.11+ 对此有警告，且可能引发死锁
信号不是万能胶，它解决的是「谁来触发」，不解决「怎么可靠执行」。真正复杂的跨服务协作，该上消息队列还是得上。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
