当后续操作不直接影响HTTP响应时，应使用post_save信号而非视图逻辑，如发邮件、更新缓存、调用第三方API等，以实现关注点分离、保障幂等性、避免阻塞请求，并配合Celery异步执行。
什么时候该用 Django 的 post_save 信号而不是直接写在视图里？
当某个动作（比如用户注册成功、订单创建完成）需要触发**不直接影响当前 HTTP 响应**的后续操作时，post_save 是首选。比如发邮件、更新统计缓存、调用第三方 API 记录日志——这些都不该阻塞用户请求，也不该让视图函数变得臃肿。
常见错误是把所有逻辑堆进 save() 方法或视图中，结果导致测试困难、复用性差、事务边界模糊。用信号能明确「谁负责触发」和「谁负责响应」的分离。
- 必须确保信号接收器函数是幂等的：同一事件可能被重复触发（比如 Celery 重试、数据库回滚后重试 save）
- 避免在信号里做耗时操作；真要异步，就用
apply_async()推给 Celery，别用threading或asyncio.create_task -
sender参数必须精确指定模型类，不要用sender=Model这种宽泛写法，否则容易误触
为什么 django.db.models.signals.pre_delete 里拿不到外键关联对象？
因为 Django 在执行 pre_delete 时，关联对象可能已被数据库级联删除（取决于 on_delete 设置），或者尚未加载进内存。此时访问 instance.foreign_key_field 很可能抛出 DoesNotExist 或返回 None。
正确做法是在 pre_delete 触发前，显式预取所需字段：
立即学习“Python免费学习笔记（深入）”；
SkillSub Pro - Python 题解与代码注释双功能技能功能概述SkillSub Pro - Python 题解与代码注释双功能技能是一项面向实际任务的技能，主要用于SkillSub Pro 是一个 Python 题解生成与代码注释的 双功能合体技能 ，专为学生、算法学习者和开发者设计；✅ 一个技能，两种用途 ：；核心要点📝 题解模式 ：输入题目/题号，自动生成完整 Python 题解（含详细注释、解题思路、复杂度分析）；💬 注释模式 ：输入 Python 代码，自动添加详细中。它将相关步骤、
@receiver(pre_delete, sender=Order)
def backup_order_data(sender, instance, **kwargs):
# 确保这里能安全访问
if hasattr(instance, '_prefetched_objects_cache'):
# 已预取过，可直接用
pass
else:
# 手动 select_related 或 prefetch_related（仅限 ORM 查询路径）
instance = Order.objects.select_related('user').get(pk=instance.pk)
- 更稳妥的方式是改用
post_delete，但注意这时对象已从 DB 删除，只能靠信号传入的instance缓存数据 - 如果必须在删除前清理关联资源（如 S3 文件），建议把关键字段（如
file_path）冗余存到本表，避免实时查关联表
如何防止信号被多次注册导致重复执行？
Django 不会自动去重信号连接，尤其在热重载开发模式下（比如 runserver 多次重启），apps.py 中的 ready() 可能被执行多次，造成同一个接收器绑定多遍。
标准解法是在 AppConfig.ready() 里加守卫：
class MyAppConfig(AppConfig):
def ready(self):
from . import signals
# 防止重复导入注册
if not hasattr(self, '_signals_registered'):
signals.connect_signals()
self._signals_registered = True
- 不要在模块顶层直接调用
connect()，那会在每次 import 时执行 - 检查是否已注册的更可靠方式是用
django.dispatch.Signal.receivers，但没必要复杂化，加个实例属性足够 - 测试时若用
TestCase，记得在tearDown清理信号（signal.disconnect()），否则影响其他测试用例
信号里访问 request 对象为什么总为 None？
信号是模型层机制，天然不感知 HTTP 请求上下文。request 只存在于视图、中间件或模板中，无法通过参数传入信号处理器。试图从线程局部变量（如 threading.local）里捞 request 是危险且不可靠的——Django 的请求生命周期和信号触发时机不同步，协程/异步视图下更会失效。
真正需要关联请求上下文的场景（比如记录操作人 IP、用户代理），应该：
- 在视图中显式将必要信息作为额外参数传给
save()，再由模型方法触发信号时带出（例如instance.save(triggered_by=request.user)） - 改用中间件 + 缓存（如
cache.set(f'request_{thread_id}', request, 30)），但仅限开发调试，生产禁用 - 接受「信号就是无上下文的」这个事实，把需要请求信息的逻辑留在视图或自定义管理命令里
信号不是万能胶，它只适合处理「模型状态变更」这一件事。想混搭请求、会话、缓存、异步任务，得靠分层设计，而不是硬塞进一个 @receiver 里。
