Django信号怎么用_Signals实现解耦的事件发布与订阅(post_save)

post_save信号应在apps.py的ready()方法中注册receiver内避免直接调用instance.save()以防循环触发bulk操作不触发该信号事务中需用on_commit保证副作用与事务一致。post_save 信号到底该在哪儿注册信号必须在 Django 应用准备好之后、模型类定义完成但尚未被大量引用前注册否则 post_save.connect() 可能失效或漏触发。最稳妥的位置是应用的 apps.py 的 ready() 方法里——不是 models.py 顶层也不是 views.py 里随便 import 的地方。常见错误现象post_save 完全不触发查日志也没调用痕迹或者只在开发服务器重启后第一次保存生效之后就静默。别把 receiver(post_save, senderMyModel) 放在 models.py 末尾模块加载顺序不稳定尤其有跨模型依赖时容易失效别在 __init__.py 或 settings.py 里注册Django 尚未完成模型扫描sender 类可能还没被识别为 ORM 模型确保 INSTALLED_APPS 中包含该应用且其 AppConfig 已启用比如在 __init__.py 中指定 default_app_configreceiver 函数里不能直接改 instance.save() 吗可以改但必须小心循环触发——post_save 是“保存后”触发如果你在里面又调用 instance.save()会再次触发同一信号形成无限递归最终爆栈或被数据库事务拦截。典型使用场景同步字段如生成 slug、发通知、更新关联统计但这些操作本身不该再触发本模型的 post_save。要避免重复保存改完数据后用 instance.save(update_fields[...])并确保 receiver 不监听 update_fields 的变化逻辑如果真需要二次保存比如补全外键加个标记字段或用 django.db.transaction.on_commit() 延迟到事务提交后执行别在 receiver 里做耗时操作如 HTTP 请求、大文件写入它运行在主请求线程中会拖慢响应应转给 Celery 或异步任务为什么有时候 post_save 没收到 createdFalsecreated 参数由 Django 内部根据 model._state.adding 判断但它可能被手动篡改或受批量操作影响。最常见原因是用了 bulk_create()、bulk_update() 或 raw SQL 插入——这些绕过 ORM 正常生命周期post_save 根本不会触发。 VWO 一个A/B测试工具