只有当两个模块本不该互相 import 但需在事件发生时触发逻辑时才用 Django 信号，如用户注册后发邮件、订单支付后更新库存；否则应直接调用函数避免流程混乱。
什么时候该用 Django 信号而不是直接调用函数？
信号不是万能胶，滥用反而让流程更难追踪。只有当两个模块本不该互相 import，但又需要在某个事件发生时触发另一段逻辑时，才适合用信号。比如：用户注册成功后发欢迎邮件、订单状态变“已支付”后更新库存、模型删除前清理关联文件——这些场景里，models.py 不该硬编码引入邮件服务或库存模块。
常见错误是把本来就在同一事务里的操作（如保存后立刻改字段）也塞进信号，结果引发事务不一致或重复执行。Django 的 post_save 在事务提交前触发，若你在里面抛异常，主事务会回滚；但 post_save 的 dispatch_uid 没设好，同一信号可能被注册多次，导致逻辑跑两遍。
- 必须用
dispatch_uid唯一标识信号接收器，尤其在 AppConfig 的ready()里注册时 - 避免在信号里做耗时操作（如发 HTTP 请求、写大文件），建议转成异步任务（Celery 或 Django Q）
- 测试时注意：
TestCase默认关闭数据库事务回滚，信号会真实触发，要用django.test.TestCase而非unittest.TestCase
如何正确注册和触发 post_save 信号？
post_save 是最常用也最容易出错的信号。它分 created=True 和 created=False 两种情况，但很多人忽略这个参数，导致新建和更新都执行同一段逻辑。
注册位置很关键：不能放在 models.py 顶层（会导致循环 import），推荐统一放在 apps.py 的 ready() 方法里：
立即学习“Python免费学习笔记（深入）”；
# myapp/apps.py
from django.apps import AppConfig
from django.db.models.signals import post_save
<p>class MyAppConfig(AppConfig):
name = 'myapp'</p><pre class='brush:python;toolbar:false;'>def ready(self):
from . import signals # 这里导入 signals 模块signals.py 示例：
# myapp/signals.py from django.db.models.signals import post_save from django.dispatch import receiver from .models import Order <p>@receiver(post_save, sender=Order) def update_inventory_on_order_save(sender, instance, created, **kwargs): if created and instance.status == 'paid': # 只在新建且已支付时触发</p><h1>更新库存逻辑...</h1><pre class='brush:python;toolbar:false;'> pass
-
instance是刚保存的模型对象，但它可能还没刷入数据库（取决于transaction.on_commit） - 如果依赖数据库最新状态（比如要查其他表），应包装进
transaction.on_commit() - 不要在信号里调用
instance.save()，否则可能无限递归触发post_save
为什么 pre_delete 信号里拿不到 ForeignKey 关联对象？
因为 pre_delete 触发时，Django 已经把外键关系从内存中清理了。比如你有个 Comment 关联 Post，在 pre_delete 里访问 comment.post 会返回 None 或抛 RelatedObjectDoesNotExist。
解决办法是提前缓存关联数据，或改用 post_delete（但此时对象已删，只能靠主键查）：
# 正确做法：在 pre_delete 前手动保留关键字段
@receiver(pre_delete, sender=Comment)
def backup_post_title_before_delete(sender, instance, **kwargs):
instance._cached_post_title = getattr(instance.post, 'title', None)
<p>@receiver(post_delete, sender=Comment)
def log_deleted_comment(sender, instance, **kwargs):
title = getattr(instance, '_cached_post_title', 'unknown')</p><h1>记录日志...</h1>-
pre_delete适合做清理（如删文件、断连接），但别依赖未持久化的关联对象 - 如果必须用关联对象，优先在
post_delete里用instance.pk查库，或在模型delete()方法里处理 - 注意：
bulk_delete()不触发任何信号，批量操作需另寻方案
自定义信号怎么传参和避免命名冲突？
内置信号参数固定，但自定义信号可以自由传参。关键是信号名要有明确语义，避免和第三方包重名（比如都叫 user_logged_in）。
定义方式：
# myapp/signals.py from django.dispatch import Signal <h1>推荐加应用前缀</h1><p>order_payment_verified = Signal( providing_args=['order_id', 'payment_method', 'amount'] )</p>
发送和接收：
# 发送端
order_payment_verified.send(
sender=Order,
order_id=order.id,
payment_method='alipay',
amount=order.total
)
<h1>接收端（同样要注册在 ready()）</h1><p>@receiver(order_payment_verified)
def send_receipt_email(sender, order_id, **kwargs):</p><h1>...</h1>- 参数尽量用简单类型（int/str/bool），别传 model 实例（容易引发 ORM 状态混乱）
- 如果参数多，考虑打包成
namedtuple或轻量 dataclass，比 dict 更易维护 - 信号名别用下划线开头（Python 私有约定），也别和 Django 内置信号同名（如
pre_init）
信号机制本质是隐式调用，调试时看不到调用栈，一旦出问题得靠日志和 django.db.connection.queries 追踪。真正解耦的前提，是你清楚每条信号谁发、谁收、何时发——而不是把它当成“自动执行”的黑盒。
