post_save 信号仅在 model.save()、create() 及显式启用的 bulk_create() 后触发，不响应 update()、bulk_update() 或原生 sql；需确保模块导入、避免同步耗时操作，并用 pre_save 或 fieldtracker 获取更新前字段值。
post_save 信号到底在什么时候触发？
它只在 Model.save() 成功写入数据库后触发，包括 create()、save()、bulk_create()（注意：后者默认不触发，需显式传 send_post_save_signal=True）。但不会在 update()、bulk_update() 或原生 SQL 操作中触发——这点常被误以为“信号没生效”。
常见错误现象：post_save 没执行，结果发现代码走的是 MyModel.objects.filter(...).update(...)；或者用了 bulk_create 却忘了加参数。
- 确认操作是否真正调用了
save()—— 比如表单form.save()是，但form.cleaned_data手动构造实例后没调.save()就不是 -
bulk_create场景下，必须显式传参：MyModel.objects.bulk_create(objs, send_post_save_signal=True) - 测试时别用
TestCase的setUpTestData预加载数据——那是在事务外插入的，post_save不会触发（除非你手动发信号）
如何安全地在 post_save 里做耗时或外部操作？
直接在 post_save 回调里发邮件、调 API、写文件，容易拖慢主请求、阻塞数据库事务，甚至引发超时或重复执行。Django 的信号是同步且无重试机制的。
正确做法是把耗时逻辑“扔出去”，交给异步任务系统处理：
- 用
celery：在信号回调里只发一个task.delay(instance.id)，让 worker 去查库、处理 - 用
django-q或huey同理，关键是「信号内只做轻量调度」 - 绝对避免在信号里直接调
requests.post或open(...)—— 一旦网络抖动或磁盘满，整个save()会失败回滚，但用户已收到 200
示例（Celery）：
@receiver(post_save, sender=Order)
def schedule_order_processing(sender, instance, created, **kwargs):
if created:
process_order_task.delay(instance.id) # 不传 instance，只传 id
为什么 receiver 有时不注册？常见注册姿势和坑
Django 不会自动扫描所有 @receiver，必须确保模块被导入过。最稳妥的位置是 apps.py 的 ready() 方法里显式导入信号模块。
常见错误现象：模型保存了，但信号函数完全没进断点；或者只在开发环境生效，部署后失效。
- 别把信号写在
models.py底部就以为万事大吉——如果该文件没被任何地方 import，Django 根本看不到它 - 推荐结构：
myapp/signals.py写接收器，myapp/apps.py的ready()里import myapp.signals - 别在信号函数里 import 模型类（比如
from .models import User），容易循环引用；改用字符串引用：sender.objects.get(...)或apps.get_model('myapp', 'User')
created 参数为 False 时，哪些字段可能还没刷新？
post_save 的 created=False 表示是更新操作，但这时 instance 的字段值是“刚传入 save() 的值”，不一定反映数据库最新状态——尤其当你用了 update_fields 或字段有 default/auto_now。
典型问题：想对比更新前后的字段值（比如记录修改日志），但直接读 instance.field 拿不到旧值。
- 需要旧值？得在
pre_save里缓存，或用django-model-utils的FieldTracker -
auto_now字段（如updated_at）在post_save里已是新值，但如果你没传update_fields，它会被自动更新；如果传了，它可能还是旧的 - 别依赖
instance.pk是否存在来判断创建/更新——pk在 update 场景下一定存在，但created才是唯一可靠依据
事情说清了就结束
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
