Signals 是 Django 对观察者模式的实现——它们让某些 senders 在特定事件发生时通知一组 receivers（比如 model 被保存或删除）。它们启用解耦代码：应用的一部分可以对另一部分的事件做出反应，而无需直接耦合。
pre_save / post_save → before / after a model instance is saved
pre_delete / post_delete → before / after a model instance is deleted
m2m_changed → a ManyToMany relationship changed
request_started / finished→ request lifecycle
user_logged_in / out → authentication events
from django.db.models.signals import post_save
from django.dispatch import receiver
# automatically create a Profile whenever a User is created
@receiver(post_save, sender=User)
def create_profile(sender, instance, created, **kwargs):
if created: # only on creation, not every save
Profile.objects.create(user=instance)
@receiver 装饰器将一个函数连接到特定 sender 的 signal。当 User 被保存时，Django 调用此函数——这里是自动创建相关的 Profile。created 标志将创建与更新区分开。
@receiver(post_save, sender=Order)
def send_order_confirmation(sender, instance, created, **kwargs):
if created:
send_email(instance.customer.email, "Order confirmed")
# the Order-creation code doesn't need to know about emails → decoupled
订单创建代码专注于订单；电子邮件逻辑单独存在并对事件做出反应——保持关注点分离。
✓ Reacting to model events from a DIFFERENT app/module (decoupling)
✓ Auto-creating related objects (Profile on User creation)
✓ Cache invalidation, search-index updates, audit logging on save/delete
✓ Cross-cutting reactions you don't want to embed in the core logic
# ⚠️ signals create IMPLICIT, "action at a distance" behavior:
# saving an Order triggers an email somewhere else — not obvious from the save call.
# This can make code HARDER to follow and debug.
When to PREFER explicit code over signals:
✗ If the logic clearly belongs in the same flow → call it directly (more readable)
✗ Overusing signals → hidden, hard-to-trace behavior, debugging difficulty
✓ A common alternative: override the model's save() method, or use a service function,
for logic tightly coupled to the operation
Use signals mainly for genuine DECOUPLING (reacting across app boundaries), not as
a default for all post-save logic.
Signals 是 Django 用于解耦代码的有用特性——让应用的不同部分可以对事件（model 保存/删除、auth 事件）做出反应，而无需直接依赖，这对跨切面关注（如自动创建相关对象、缓存失效、审计日志以及跨应用边界响应事件）非常有价值。
理解它们对正确使用它们和在现有代码库中识别它们都很重要（它们是