Django怎么利用信号处理业务_Python使用post_save解耦模型操作

先明确一个核心问题：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 才是唯一可靠依据