信号注册必须在Django应用加载完成前完成，推荐在apps.py的ready()方法中调用connect()并指定dispatch_uid防重复；receiver函数须声明为def handler(sender, **kwargs)，避免硬编码参数，且不可异步执行。
信号注册必须在 Django 应用加载完成前完成
信号不是“声明即生效”，django.dispatch.Signal 实例本身不自动绑定，必须显式调用 connect()，且该调用必须发生在 Django 的应用注册和配置加载阶段之后、服务启动之前。否则信号发出去了，没人监听。
常见错误现象：post_save 信号触发但自定义处理函数完全没执行；调试发现 receiver 装饰器看似生效，实际模块根本没被导入。
- 把信号接收器写在
apps.py的ready()方法里是最稳妥的做法（Django 官方推荐） - 避免放在
models.py末尾直接connect()—— 某些导入顺序下，该文件可能被提前加载，而此时 ORM 尚未就绪，会报AppRegistryNotReady - 如果用
@receiver装饰器，确保装饰的模块已被 Django 自动发现（即在INSTALLED_APPS中，且包结构符合 app 配置）
receiver 函数参数不能硬编码，要兼容 sender 和 **kwargs
Django 信号传递参数是动态的，不同信号传的字段不同，比如 pre_save 有 raw、using，post_delete 根本不传 instance（它已删）。硬写 def my_handler(sender, instance) 在某些信号下会直接抛 TypeError。
使用场景：你写了通用日志信号处理器，想同时接 post_save 和 post_delete，但参数签名不一致就会崩。
立即学习“Python免费学习笔记（深入）”；
- 所有 receiver 函数必须声明为
def handler(sender, **kwargs):，靠kwargs.get('instance')或kwargs.get('created')安全取值 - 用
sender参数做类型判断（如if sender == MyModel:），别依赖kwargs里一定有某个 key - 不要在 receiver 里做耗时操作（如发邮件、调第三方 API），默认是同步阻塞执行，会拖慢主流程
异步响应必须手动解耦，Django 信号本身不支持 async/await
即使你的视图或命令是 async 的，post_save 这类信号的 receiver 仍只能是普通同步函数。Django 的信号分发机制完全基于同步调用栈，async def receiver 会被忽略或报错。
性能影响：在 receiver 里直接 await 或丢进 asyncio.create_task() 是无效的——事件循环可能不存在，或上下文已销毁。
- 真正可行的异步路径只有两条：用
threading.Thread启新线程（适合轻量 IO），或发消息到任务队列（如 Celery 的task.delay()） - Celery 推荐用
@shared_task+sender判断，而不是在 receiver 里直接调task.delay()—— 后者会让任务强依赖当前请求生命周期，容易丢任务 - 注意事务边界：
post_save在事务提交前触发，若需等事务真正落库再执行异步动作，得用transaction.on_commit(lambda: task.delay())
disconnect 不常用但关键，尤其测试和热重载场景
信号是全局注册的，模块重载、测试用例间不清理，会导致同一个 handler 被重复注册多次，一次信号触发多次执行 —— 数据重复写入、日志爆炸、任务重复创建都是典型表现。
容易踩的坑：本地开发用 runserver 热重载时，ready() 可能被反复调，但 connect() 没配 dispatch_uid，结果 handler 注册了 N 份。
- 给每个
connect()加唯一dispatch_uid='myapp_user_created_notifier'，Django 会自动去重 - 单元测试中，在
setUp里connect()，在tearDown里显式disconnect()，避免测试污染 -
disconnect()必须用和connect()完全相同的参数（包括dispatch_uid），否则无效
