post_delete信号不能直接删文件，因其在事务提交后触发，此时模型字段可能不可靠且事务回滚会导致误删；应改用pre_delete获取路径并配合on_commit安全删除。
为什么 post_delete 信号不能直接删文件？
因为 Django 的 post_delete 信号在事务提交后才触发，而此时模型实例的字段（比如 FileField 的 path）可能已不可靠——数据库行已被删除，instance.file_field.path 可能抛出 ValueError 或返回空字符串。更糟的是，如果事务回滚，post_delete 仍会执行，导致误删未真正删除的文件。
正确做法：用 pre_delete + 手动保存路径
必须在模型被删之前拿到文件路径并缓存下来。常见可靠方式是在模型上加一个临时属性，或在 signal handler 中通过 sender._meta.get_field() 提前读取：
- 在
pre_delete里调用instance.file_field.path（此时字段值仍完整） - 把路径传给自定义清理函数，**不要依赖
instance在 signal 外部的状态** - 确保路径存在再删：
if os.path.exists(path) and os.path.isfile(path) - 别忘了同时删掉
file_field对应的_delete行为（如缩略图、S3 的额外副本）
Django 4.2+ 的 FileField 自带 storage.delete() 风险点
直接调用 instance.file_field.delete(save=False) 看似方便，但有坑：
- 它会清空字段值并触发 storage 的
delete()，但若你在pre_delete里这么干，Django 后续的delete()流程可能因字段为空报错 - 对
FileSystemStorage是安全的；但对S3Boto3Storage等第三方 storage，delete()可能异步失败且无重试 - 推荐绕过 model 层，用
default_storage.delete(path)更可控，且不干扰 ORM 生命周期
信号注册和事务边界必须显式处理
默认情况下，pre_delete 在事务内运行，但文件系统操作不应受 DB 事务控制——删文件失败不该导致 DB 回滚（否则数据不一致）。所以：
立即学习“Python免费学习笔记（深入）”；
- 用
@receiver(pre_delete, sender=MyModel)注册，**不要用dispatch_uid拼字符串**（易冲突） - 删文件逻辑必须包裹在
transaction.on_commit(lambda: ...)外层，或明确设为非事务性（如用threading.local缓存路径后另起线程） - 生产环境务必加日志和异常捕获：
try...except OSError，避免 signal handler 崩溃阻塞整个 delete 流程
最简健壮写法其实是：在 pre_delete 里取 path → 存进 django.core.cache.cache（带 timeout）→ 在 on_commit 里取出来删。这样既解耦，又避开事务陷阱。
