软删除必须用模型字段（如deleted_at）标记状态，配合自定义manager过滤、重写delete()方法实现软删逻辑，并需统一处理批量操作与信号兼容性。
软删除字段必须是模型字段且可为空
软删除的本质是用一个字段标记“逻辑删除”状态，而不是真从数据库删掉。Django 的 Manager 过滤依赖这个字段的值，所以它必须定义在模型里，且类型要支持 NULL（比如 DateTimeField(null=True, blank=True) 或 BooleanField(default=False)）。如果误用 CharField(default='') 或没设 null=True，后续过滤时 isnull 查询会失效，导致已“删除”的数据仍被查出来。
常见错误现象：MyModel.objects.all() 返回了本该隐藏的记录；MyModel.deleted_objects.all() 报 FieldError。
- 推荐用
deleted_at = models.DateTimeField(null=True, blank=True)：语义清晰，方便按时间排序/恢复 - 避免用
is_deleted = models.BooleanField(default=False)后又手动设True：容易和业务字段混淆，且无法区分“未删”和“删于何时” - 字段名统一用
deleted_at，别用is_deleted、removed等混用命名，否则 Manager 里写死的字段名容易出错
自定义 Manager 要重写 get_queryset() 并链式返回
Django 4 的 Manager 默认不自动过滤，必须显式在 get_queryset() 中加条件。重点不是“写个新 Manager”，而是确保所有调用（包括 .filter()、.exclude()、.first()）都走这个逻辑 —— 所以必须返回一个带 .filter(deleted_at__isnull=True) 的 QuerySet 实例，不能只 return [] 或硬编码列表。
示例写法：
class SoftDeleteManager(models.Manager):
def get_queryset(self):
return super().get_queryset().filter(deleted_at__isnull=True)
<p>class MyModel(models.Model):
deleted_at = models.DateTimeField(null=True, blank=True)
objects = SoftDeleteManager()
all_objects = models.Manager() # 保留原始查询入口
</p>
- 务必继承
models.Manager，别用models.QuerySet：后者不能直接挂到模型上 - 一定要调用
super().get_queryset()再链式 filter，不能直接MyModel.objects.filter(...)：否则递归调用自己，爆栈 - 显式声明
all_objects = models.Manager()：不然没法查含已删数据的报表或后台管理
delete() 方法要覆盖成软删而非真删
光靠 Manager 过滤不够，用户调 instance.delete() 时默认还是物理删除。必须重写模型的 delete() 方法，把行为改成更新 deleted_at 字段。注意：这不会触发 post_delete 信号，但会触发 pre_save 和 post_save（因为是 save 操作）。
图片提示词生成器？不止如此。 马甲系统 —— 把脑海中的画面，翻译成AI能理解的专业表达。 用得越多，它越懂你：首次需要多问几句确认方向，用久了几乎一说就懂。 用得越多，它越快：缓存机制让后续对话越来越省。 RAG进化：成功案例持续入库，越跑越聪明。 输入「新手指南」查看完整功能介绍
错误做法：def delete(self): self.deleted_at = timezone.now(); self.save() —— 缺少 using 参数，多数据库路由失败；没处理批量删除场景。
- 标准写法要接收
*args, **kwargs并透传using： def delete(self, *args, **kwargs): self.deleted_at = timezone.now(); self.save(update_fields=['deleted_at'], using=kwargs.get('using'))- 如果项目用了
django-admin的批量删除（如 admin 列表页勾选删），需额外重写MyModel._meta.model.delete()类方法，或改用自定义 admin 动作 - 别在
delete()里调super().delete()：那会真删，和软删目标冲突
QuerySet 方法（如 update、bulk_update）绕过 Manager 过滤
这是最容易被忽略的坑：Manager 的 get_queryset() 只影响 .all()、.filter() 这类“读取”操作。一旦调 .update(deleted_at=...) 或 .bulk_update()，Django 直接发 SQL，完全不经过 Manager 过滤，可能误更新“已被软删”的记录，或漏更新本该软删的行。
比如：MyModel.objects.filter(name='test').update(deleted_at=timezone.now()) 看似在软删，但如果 MyModel.objects 是软删 Manager，这个 filter() 其实已经排除了 deleted_at__isnull=False 的行 —— 导致“二次软删”失效。
- 安全做法：用
MyModel.all_objects.filter(...).update(...)显式走全量 Manager - 批量软删建议封装成模型类方法：
def soft_delete_bulk(queryset): queryset.update(deleted_at=timezone.now())，并文档注明“入参必须来自all_objects” - 测试时重点覆盖：
MyModel.all_objects.count()vsMyModel.objects.count()差值是否等于软删数
软删除不是加个字段+改个 Manager 就完事，关键在 delete 行为、批量操作、信号兼容这三处——漏一个，数据一致性就破了。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
