先明确一个核心问题：Django信号到底是用来干什么的？简单说，它让你在模型操作“之后”自动执行一些逻辑，比如保存订单后发个邮件、更新缓存。但很多开发者在实际用的时候，发现信号要么不触发，要么触发了不是自己想要的，要么拖慢了整个请求。
这篇文章就专门聊聊post_sa ve信号——最常见的几个坑和正经用法，一次性说透。
post_sa ve 信号到底在什么时候触发？
它只在 Model.sa ve() 成功写入数据库后触发，包括 create()、sa ve()、bulk_create()（注意：后者默认不触发，需显式传 send_post_sa ve_signal=True）。但不会在 update()、bulk_update() 或原生 SQL 操作中触发——这点常被误以为“信号没生效”。
常见错误现象：post_sa ve 没执行，结果发现代码走的是 MyModel.objects.filter(...).update(...)；或者用了 bulk_create 却忘了加参数。
- 确认操作是否真正调用了
sa ve()—— 比如表单form.sa ve()是，但form.cleaned_data手动构造实例后没调.sa ve()就不是 bulk_create场景下，必须显式传参：MyModel.objects.bulk_create(objs, send_post_sa ve_signal=True)- 测试时别用
TestCase的setUpTestData预加载数据——那是在事务外插入的，post_sa ve不会触发（除非你手动发信号）
如何安全地在 post_sa ve 里做耗时或外部操作？
直接在 post_sa ve 回调里发邮件、调 API、写文件，容易拖慢主请求、阻塞数据库事务，甚至引发超时或重复执行。Django 的信号是同步且无重试机制的。
正确做法是把耗时逻辑“扔出去”，交给异步任务系统处理：
- 用
celery：在信号回调里只发一个task.delay(instance.id)，让 worker 去查库、处理 - 用
django-q或huey同理，关键是「信号内只做轻量调度」 - 绝对避免在信号里直接调
requests.post或open(...)—— 一旦网络抖动或磁盘满，整个sa ve()会失败回滚，但用户已收到 200
示例（Celery）：
@receiver(post_sa ve, 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_sa ve 的 created=False 表示是更新操作，但这时 instance 的字段值是“刚传入 sa ve() 的值”，不一定反映数据库最新状态——尤其当你用了 update_fields 或字段有 default/auto_now。
典型问题：想对比更新前后的字段值（比如记录修改日志），但直接读 instance.field 拿不到旧值。
- 需要旧值？得在
pre_sa ve里缓存，或用django-model-utils的FieldTracker auto_now字段（如updated_at）在post_sa ve里已是新值，但如果你没传update_fields，它会被自动更新；如果传了，它可能还是旧的- 别依赖
instance.pk是否存在来判断创建/更新——pk在 update 场景下一定存在，但created才是唯一可靠依据
