Django软删除实现：重写delete()与Manager过滤

本文深入剖析了 Django 中软删除的正确实现方式，强调必须优先重写 `QuerySet.delete()` 而非模型实例的 `delete()` 方法，以避免破坏外键级联（如 `CASCADE` 失效导致数据不一致）、保障批量操作和事务安全；同时指出自定义 Manager 需同步重写 `get_queryset()`（过滤读取）与 `delete()`（拦截写入），但真正可靠的拦截点在于继承 `QuerySet` 并重写其 `delete()` 方法，配合 `update()` 实现高效、原子性的软删；文章还提醒了字段命名（`is_deleted` 优于 `deleted`）、迁移策略（禁用 `default=timezone.now`，需手动补全历史数据）、反向关系处理及 GDPR 等合规场景下硬删后门的必要性——软删除不是“加个标志位”那么简单，而是贯穿设计、实现、测试与演进的系统性工程。

直接改 delete() 方法会破坏外键级联

Django 默认的 delete() 是真删，一旦你重写它让模型“假装删除”，外键关联的 on_delete=models.CASCADE 就不会触发——不是 bug，是设计如此。比如 Order 关联 OrderItem，你只把 Order.is_deleted = True，OrderItem 还在库里，数据就脏了。

实操建议：

• 别直接覆盖模型实例的 delete() 方法，除非你手动处理所有关联对象（极容易漏）
• 优先用自定义 Manager 控制查询入口，再配合 QuerySet.delete() 的重写（见下一条）
• 如果必须重写实例 delete()，务必检查所有 ForeignKey 字段的 on_delete 行为，并在方法里显式调用关联对象的软删逻辑

Manager 要同时重写 get_queryset() 和 delete()

只在 get_queryset() 里加 .filter(is_deleted=False)，能让 MyModel.objects.all() 不查出已软删数据，但 MyModel.objects.filter(...).delete() 还是会真删——因为 Django 的 QuerySet.delete() 绕过了 Manager，直连数据库。

实操建议：

• 自定义 Manager 必须同时重写 get_queryset()（过滤读）和 delete()（拦截写）
• delete() 方法里不要调用 super().delete()，而是批量更新 is_deleted=True 和 deleted_at
• 注意：重写的 delete() 只对 Manager 调用生效（如 MyModel.objects.filter(...).delete()），对实例调用（obj.delete()）无效，后者仍走模型方法

class SoftDeletableManager(models.Manager):
    def get_queryset(self):
        return super().get_queryset().filter(is_deleted=False)
<pre class="brush:python;toolbar:false;">def delete(self):
    # 注意：这是 Manager 的 delete，不是 QuerySet 的
    # 实际要用 QuerySet.delete() 的重写，更推荐如下方式：
    return self.get_queryset().update(
        is_deleted=True,
        deleted_at=timezone.now()
    )

QuerySet.delete() 重写比 Manager 更可靠

Manager 的 delete() 方法其实不常用，真正被链式调用的是 QuerySet.delete()。Django 在执行 .filter(...).delete() 时，调用的是 QuerySet 类的方法，不是 Manager 的。所以拦截点要放在 QuerySet 上。

实操建议：

• 定义一个继承 models.QuerySet 的类，重写它的 delete()
• 在 Manager 中用 get_queryset() 返回这个自定义 QuerySet
• 确保 delete() 里用 self.update(...)，而不是 self._raw_delete(...) 或循环调实例 delete()（性能差、不事务安全）
• 如果模型有 GenericForeignKey 或第三方关系（如 django-polymorphic），软删后需额外清理反向关系缓存

字段命名和迁移容易踩的坑

用 is_deleted 比 deleted 更明确，避免和布尔字段默认值混淆；deleted_at 推荐用 DateTimeField(null=True, blank=True)，别设默认值 timezone.now——迁移时会固化成时间戳，不是运行时值。

实操建议：

• 添加字段时用 makemigrations --empty 手动写迁移，在 operations 里先 AddField，再 RunPython 把历史数据 is_deleted=False 补全，否则老数据查不到
• 别用 default=False 加 is_deleted 字段：已有记录会自动填 False，看似没问题，但万一某次迁移漏跑或回滚，状态就不可逆
• 测试时重点验证：硬删（force_delete=True 场景）、软删后 admin 列表是否隐藏、API 返回是否过滤、信号（pre_delete）是否还触发

软删除真正的复杂点不在代码怎么写，而在于「什么时候必须真删」——比如 GDPR 要求彻底擦除用户数据，或者审计日志要求不可篡改，这时候软删反而成了技术债。得提前在模型设计里留好 hard_delete() 后门，而不是指望后期补。

本篇关于《Django软删除实现：重写delete()与Manager过滤》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于文章的相关知识，请关注golang学习网公众号！