Django Signals 是什么？适合解决什么问题，使用时有哪些坑？

简化版

Django Signals 是一种发布订阅机制，用来在某些事件发生时通知接收函数，例如模型保存后的 post_save、删除后的 post_delete。它适合做解耦的旁路动作，但不适合承载核心业务流程，因为调用链隐蔽、调试困难、容易重复注册。

详细版

Signal 的基本组成是：信号发送者、信号对象、接收函数。Django 内置了模型生命周期、请求生命周期、迁移等多类信号；最常见的是在模型保存后同步创建资料、清理缓存、记录审计日志。

示例：

from django.db.models.signals import post_save
from django.dispatch import receiver

@receiver(post_save, sender=User)
def create_profile(sender, instance, created, **kwargs):
    if created:
        Profile.objects.create(user=instance)

面试里要强调边界：Signal 让模块解耦，但也让控制流变隐式。核心业务强一致逻辑更适合显式调用服务函数；Signal 更适合非主流程、副作用清晰、失败影响可控的动作。

完整版教学

一、为什么 Django 需要 Signals

大型 Django 项目里，一个事件常常会引发多个旁路动作。比如用户注册成功后，要创建用户资料、发送欢迎邮件、写审计日志、清理某些缓存。如果这些动作都直接写在注册函数里，注册逻辑会越来越臃肿。

Signal 提供的是一种“事件发生了，感兴趣的人自己订阅”的机制。注册逻辑只负责保存用户，其他模块通过订阅 post_save 感知用户创建。这样模块之间的直接依赖减少，但代价是调用链不再一眼可见。

User.save()
   |
post_save signal
   |
   +--> create_profile
   +--> write_audit_log
   +--> clear_cache

这个机制适合做扩展点，不适合把主业务藏起来。面试时可以说：Signal 是解耦工具，但解耦不是免费午餐，隐式控制流会增加排查成本。

二、Signal 的调用模型

一个 Signal 可以有多个 receiver。发送信号时，Django 会按注册情况调用接收函数，并把 sender、instance、created 等上下文参数传进去。对于模型信号，sender 通常是模型类，instance 是当前模型对象。

@receiver(post_save, sender=Order)
def after_order_saved(sender, instance, created, **kwargs):
    if created:
        print("new order", instance.id)

常见模型信号如下：

信号	触发时机	常见用途
`pre_save`	模型保存前	补字段、校验边界
`post_save`	模型保存后	创建关联记录、清缓存
`pre_delete`	删除前	检查依赖、记录快照
`post_delete`	删除后	清理外部资源
`m2m_changed`	多对多关系变化	更新统计、同步权限

注意，Signal receiver 默认是同步执行的。一次请求里触发 post_save 后，receiver 慢了，请求也会被拖慢；receiver 抛异常，也可能影响当前保存流程。

三、注册位置为什么容易踩坑

Django 项目常见问题是 receiver 没注册或重复注册。没注册通常是因为信号模块没有被导入；重复注册可能出现在开发服务器自动重载、测试重复初始化、导入路径混乱等场景。

推荐做法是把信号注册放在 app 的 apps.py 里，通过 AppConfig.ready() 导入 signals 模块：

class AccountsConfig(AppConfig):
    name = "accounts"

    def ready(self):
        import accounts.signals

如果担心重复注册，可以给 receiver 设置 dispatch_uid。这相当于给接收器一个稳定身份，避免同一个逻辑被重复连接。

post_save.connect(
    create_profile,
    sender=User,
    dispatch_uid="accounts.create_profile",
)

Signal 的第一个排查点永远是“它到底有没有被导入注册，以及有没有被重复注册”。

四、Signals 和事务的关系

post_save 的“保存后”不等于“事务提交后”。如果代码在 transaction.atomic() 里保存模型，post_save 会在 save() 后触发，但外层事务可能稍后回滚。此时如果 receiver 里发了消息、发了邮件、调用了外部接口，就可能出现数据库回滚但外部副作用已经发生的问题。

更稳妥的做法是在需要事务提交后再执行副作用时使用 transaction.on_commit()：

from django.db import transaction

@receiver(post_save, sender=Order)
def order_saved(sender, instance, created, **kwargs):
    if created:
        transaction.on_commit(lambda: publish_order_created(instance.id))

数字化理解：100 个订单创建请求里，如果有 2 个因为后续校验回滚，而你在 post_save 里直接发 MQ，那么消费者会看到 2 条数据库里不存在的订单事件。on_commit 可以把副作用推迟到事务真正提交之后。

五、什么时候不该用 Signals

如果某个动作是主业务必需步骤，就不要用 Signal 藏起来。比如“下单必须扣库存、冻结优惠券、生成支付单”，这些最好写在显式服务流程里，让调用方知道失败如何处理、顺序如何保证、事务边界在哪里。

Signal 更适合这些场景：

适合	不适合
审计日志	核心交易流程
清缓存	强一致状态迁移
创建非关键关联记录	需要复杂编排和回滚的流程
发送统计事件	调用链必须清晰可追踪的逻辑

判断标准是：receiver 失败时，主流程是否还能接受。如果不能接受，就不要把它藏在 Signal 里。

六、性能和可观测性怎么做

Signal receiver 是普通 Python 函数，慢查询、网络请求、复杂计算都会增加当前请求耗时。一个 post_save 后面如果挂了 5 个 receiver，每个平均 30ms，请求就可能额外增加约 150ms，还不算数据库锁和事务等待。

工程上要给 receiver 做清晰命名、日志、指标和错误处理。耗时副作用应该丢到 Celery/RQ 等任务队列，而不是在 receiver 里同步做完。

@receiver(post_save, sender=Order)
def enqueue_order_event(sender, instance, created, **kwargs):
    if created:
        transaction.on_commit(lambda: send_order_event.delay(instance.id))

这样 Signal 只负责把“事件发生”转成异步任务，真正耗时的外部调用交给 worker。主请求更稳定，失败也有重试和监控入口。

七、常见误区与追问

误区：post_save 表示事务已经提交。 它只表示 save() 调用完成；外层事务仍可能回滚，外部副作用要考虑 on_commit。
误区：Signals 越多越解耦，代码越好。 过多 Signal 会让业务链路隐蔽，排查和测试都变难。
误区：receiver 一定异步执行。 Django Signals 默认同步调用，receiver 慢会拖慢当前流程。
追问：Signal 没触发怎么办？ 先检查 signals 模块是否在 AppConfig.ready() 中导入，再查 sender、注册函数、导入路径。
追问：如何避免重复注册？ 使用稳定导入位置，并在手动 connect 时设置 dispatch_uid。
追问：Signal 里能发邮件吗？ 可以，但最好在事务提交后投递异步任务，避免请求阻塞和事务回滚副作用。
追问：Signal 和显式服务调用怎么选？ 核心强一致流程显式调用；旁路、可重试、失败影响可控的扩展动作可以用 Signal。

八、加强记忆

把 Django Signals 记成“事件通知，不是业务编排”。它能让保存模型后的旁路动作解耦，但也会让调用链变暗；post_save 不等于事务提交，耗时副作用不要同步塞在 receiver 里。面试回答时按“机制是什么 -> 注册在哪里 -> 事务边界 -> 适用场景 -> 坑和治理”展开，就能体现你用过它，也知道什么时候该克制。

简化版

详细版