post_save信号必须在apps.py的ready()方法中注册，否则易失效；receiver内禁用instance.save()防循环触发；bulk操作不触发该信号；事务中需用on_commit保证一致性。
post_save 信号必须在 apps.py 的 ready() 中注册
不注册在 ready() 方法里，post_save 很可能压根不触发——尤其在模块热重载、跨应用引用或测试环境下。Django 扫描模型后才构建信号连接，早了（如 models.py 顶层）或晚了（如视图里 import）都会失效。
常见错误现象：print 日志完全没输出；或者只在开发服务器首次启动时生效一次，之后静默。
- 确保应用已加入
INSTALLED_APPS，且AppConfig已启用（例如在apps.py中定义并配置default_app_config） - 在
apps.py的ready()里 import 信号模块，不要直接写逻辑——避免循环导入 - 别用
weak=False除非你明确需要强引用；默认弱引用更安全，但接收器不能是局部函数
receiver 函数里改数据要防循环 save
post_save 是“保存完成之后”触发的，如果你在里面又调用 instance.save()，会再次触发同一信号，形成递归调用，最终爆栈或被事务回滚拦截。
典型使用场景是补全字段（比如生成 slug）、同步统计、发通知，但这些操作本身不该再触发本模型的 post_save。
- 真要更新字段，用
instance.save(update_fields=['field1', 'field2'])，并确认你的信号监听逻辑不依赖这些字段变化 - 如果必须二次保存（比如补全外键关联），加个标记字段（如
_skip_post_save）或用django.db.transaction.on_commit()延迟到事务提交后执行 - 绝对不要在 receiver 里做耗时操作：HTTP 请求、文件写入、复杂计算——它们会卡住整个请求线程；应交给 Celery 或异步任务（如
send_email_task.delay(instance.id)）
bulk 操作不触发 post_save，别指望它监听批量导入
bulk_create()、bulk_update()、raw SQL 插入等绕过 ORM 正常生命周期的操作，post_save 一概不触发。这不是 bug，是设计使然——性能优先。
快速生成专业的 Python 脚本和应用代码。一键创建完整项目结构，支持CLI、API、爬虫、Bot、Django等多种项目类型，包含完整的项目结构、配置文件、依赖管理、测试、README和文档。
如果你的业务依赖“每次创建都发通知”，但又用了批量导入，就会漏掉大量通知。
- 检查是否误用了
bulk_create而非单条save()；对小批量（save() - 若必须 bulk，把通知逻辑抽出来单独调用，比如在命令脚本末尾统一处理
created_ids -
created参数不可靠：它由instance._state.adding判断，而这个状态可能被手动修改或受事务影响；别仅靠它判断“是不是新对象”
信号不是万能解耦，该直调就直调
信号看似松耦合，但容易导致隐式依赖、调试困难、执行顺序难控。Django 官方文档也明确警告：“在可能的情况下，你应该选择直接调用处理代码，而不是通过信号进行分发。”
真正适合信号的场景是：事件源明确、副作用可容忍延迟、接收方与发送方无强业务语义绑定（比如用户注册后发欢迎邮件、订单支付成功后扣减库存）。其他情况，比如“保存订单时校验优惠券”，更适合放在 model 的 clean() 或 form 的 clean() 中。
最容易被忽略的一点：信号是同步执行的，它和主请求共用一个数据库事务。一旦 receiver 抛异常，整个事务会回滚——这有时是预期行为，有时却是灾难。务必确认 receiver 内部逻辑是否允许失败、是否需要补偿机制。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
