不能直接用delete()方法，因为Django默认delete()触发物理删除且绕过模型逻辑；软删除须统一改为更新deleted_at字段，并重写Manager、QuerySet及关联行为以确保全链路过滤与一致性。
为什么不能直接用 delete() 方法
因为 Django 默认的 delete() 会触发 SQL 的 DELETE FROM，数据彻底从表中消失，无法恢复。软删除的本质是“标记删除”而非物理删除，核心在于把删除动作转为字段更新。
常见错误是只加一个 is_deleted 字段但忘记拦截所有查询和删除逻辑——结果后台标了已删，前端还能查出来，或者调用 obj.delete() 后数据真没了。
- 必须重写模型的
delete()方法，改为更新状态字段 - 必须重写默认 Manager，让
objects.all()自动过滤掉已软删记录 - 需要额外提供一个
all_objects（或类似名称）Manager 来查含软删数据的全集 - 外键级联删除、
bulk_delete等批量操作不会走单实例delete()，需单独处理
如何定义带软删除的基类模型
推荐用抽象基类统一实现，避免每个模型重复写逻辑。关键点是：字段命名要明确（比如用 deleted_at 而非模糊的 is_deleted），便于后续做时间范围查询和清理。
from django.db import models
from django.utils import timezone
<p>class SoftDeleteModel(models.Model):
deleted_at = models.DateTimeField(null=True, blank=True, db_index=True)</p><pre class="brush:php;toolbar:false;">class Meta:
abstract = True
def delete(self, using=None, keep_parents=False):
self.deleted_at = timezone.now()
self.save(update_fields=['deleted_at'])
def hard_delete(self):
super().delete()
@property
def is_deleted(self):
return self.deleted_at is not None
立即学习“Python免费学习笔记（深入）”；
注意：db_index=True 对 deleted_at 加索引，否则带 WHERE deleted_at IS NULL 的查询可能变慢；update_fields 避免触发其他字段的 pre_save 信号或冗余更新。
如何让 QuerySet 自动过滤软删数据
Django 的 Manager 控制 Model.objects 的行为。默认 Manager 必须只返回未删数据，否则所有现有代码（如 User.objects.filter(...)）都会意外查到“已删”记录。
- 自定义 Manager 继承
models.Manager，重写get_queryset() - 在基类里直接绑定
objects = SoftDeleteManager()，子类自动继承 - 务必提供另一个 Manager（如
all_objects）暴露原始数据，用于后台管理、恢复、归档等场景
class SoftDeleteManager(models.Manager):
def get_queryset(self):
return super().get_queryset().filter(deleted_at__isnull=True)
<p>class SoftDeleteModel(models.Model):</p><div class="aritcle_card flexRow">
<div class="artcardd flexRow">
<a class="aritcle_card_img" href="/xiazai/skill11526" title="Python Hardener"><img
src="https://img.php.cn/upload/skill/001/246/273/6adaf20dbae7c507.jpg" alt="Python Hardener" ></a>
<div class="aritcle_card_info flexColumn">
<a href="/xiazai/skill11526" title="Python Hardener">Python Hardener</a>
<p>通过完整的安全审查、代码整洁重构、健壮的错误处理、正确的日志记录以及完整的文档字符串覆盖，强化 Python 脚本。</p>
</div>
<a href="/xiazai/skill11526" title="Python Hardener" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span> </a>
</div>
</div><h1>... 字段同上</h1><pre class="brush:php;toolbar:false;">objects = SoftDeleteManager()
all_objects = models.Manager() # 不过滤，查全部
class Meta:
abstract = True
立即学习“Python免费学习笔记（深入）”；
别漏掉 all_objects —— 比如管理员想看“最近7天被删的订单”，就得靠它查 Order.all_objects.filter(deleted_at__gte=...)。
外键关联和批量操作怎么处理
外键默认 on_delete=models.CASCADE 是硬删行为，软删除模型被“删”后，关联对象不会自动软删，甚至可能因外键约束报错（如果数据库层设了 ON DELETE CASCADE）。这是最容易被忽略的断裂点。
- 外键字段加
on_delete=models.SET_NULL并设null=True，避免级联硬删 - 批量删除（如
QuerySet.delete()）不走单实例delete()，必须手动遍历或重写 QuerySet - 如果必须支持
qs.delete()软删，需自定义 QuerySet 类并挂载到 Manager
例如补充一个可软删的 QuerySet：
class SoftDeleteQuerySet(models.QuerySet):
def delete(self):
return self.update(deleted_at=timezone.now())
<p>class SoftDeleteManager(models.Manager):
def get_queryset(self):
return SoftDeleteQuerySet(self.model, using=self._db).filter(deleted_at__isnull=True)
这样 MyModel.objects.filter(...).delete() 就会批量更新 deleted_at，而不是执行 SQL DELETE。
软删除真正难的不是加个字段，而是让整个 ORM 层（查询、删除、关联、批量、迁移、管理后台）都按同一套规则响应。漏掉任意一环，数据一致性就破了。
