Django post_delete信号抛异常后实例仍存在于数据库问题

你对post_delete信号的触发边界存在理解偏差：该信号是在数据库DELETE语句执行完成后立即发送，不是在所在数据库事务提交完成后发送。

• Django的模型删除操作默认运行在数据库事务中：调用delete()方法后，pre_delete信号发送、DELETE SQL执行、post_delete信号发送这几个步骤全在同一个事务上下文里。
• 数据库事务的原子性规则决定了：只要事务流程中任意位置抛出未捕获的异常，整个事务就会回滚，之前已经执行的DELETE操作也会被撤销，最终表现就是对象仍然留在数据库中。
• 官方文档提到的「对象不再存在于数据库中」，描述的是DELETE语句执行完、事务未提交也未回滚的瞬时状态，并没有覆盖事务回滚的场景。如果post_delete接收器抛出异常触发回滚，对象自然会恢复。

你的测试代码对应的实际执行流程：

1. 调用删除方法，若当前无活跃事务则自动开启新事务
2. 发送pre_delete信号
3. 执行DELETE语句，此时对应数据行在当前事务视角下已被删除，但变更未持久化到数据库
4. 发送post_delete信号，你的回调函数在此处抛出异常
5. 异常未被捕获，事务触发回滚，DELETE操作被撤销
6. 异常向上抛出到业务层，此时查询数据库会发现对象仍然存在

如果post_delete中需要执行不影响主删除流程、或者必须等数据真正持久化后才运行的逻辑（比如清理关联的静态文件、发送删除通知消息），不要直接把逻辑写在信号回调里，也不要让未捕获的异常阻断主事务：

• 对非核心的后置逻辑做好异常捕获，避免异常抛到事务流程里触发回滚
• 对要求数据强一致的后置逻辑，用transaction.on_commit()把逻辑注册到事务提交成功后再执行，参考写法：

from django.db import transaction
from django.db.models.signals import post_delete
from django.dispatch import receiver

@receiver(post_delete, sender=Dummy)
def post_delete_callback(sender, instance, **kwargs):
    def run_after_commit():
        # 只有数据真正删除持久化后才会执行这部分逻辑
        print("执行删除后置任务：清理关联文件、发送通知等")
    transaction.on_commit(run_after_commit)

内容的提问来源于stack exchange，提问作者Piyush Kumar