MongoDB逻辑删除需用status字段而非布尔值，配合partialIndex提升查询效率；所有读操作必须显式添加status: "active"条件，索引需用{status: "active"}而非$ne，硬删前须检查引用和缓存。
MongoDB 本身不提供开箱即用的逻辑删除机制，deleteOne() 和 deleteMany() 都是物理删除。要实现“软删”，最轻量、最可控的方式就是在业务文档里加一个 status 字段（比如 "status": "active" 或 "status": "deleted"），再配合 partialIndex 提升查询效率和一致性。
为什么用 status 而不是 isDeleted 布尔值？
布尔字段（如 isDeleted: true/false）语义单一，但扩展性差；status 是字符串枚举，后续容易追加 "archived"、"pending_review" 等状态，避免频繁改表结构。更重要的是：partialIndex 对 status 的过滤更自然——你只需要索引非删除态的文档，而不是“排除 true”。
-
status: "deleted"表示已逻辑删除，所有业务读取默认忽略该值 - 插入时显式设
status: "active"，不能依赖默认值（驱动或 ORM 可能不传该字段） - 更新删除动作只改
status，不删文档，也不动_id或其他字段 - 别用
null或缺失字段表示“未删除”——partialIndex无法可靠覆盖这种隐式语义
如何创建有效的 Partial Index 来加速逻辑删除查询
Partial Index 只对满足条件的文档建索引，既节省空间，又让 find({ status: "active" }) 这类查询天然走索引。但写法不对会白忙活：
- 正确写法：
db.collection.createIndex({ createdAt: 1 }, { partialFilterExpression: { status: "active" } }) - 错误写法：
{ status: { $ne: "deleted" } }——partialFilterExpression不支持$ne，只接受等值或存在性表达式（$exists） - 如果业务常按用户 ID 查有效数据，建议复合索引：
{ userId: 1, createdAt: -1 }+partialFilterExpression: { status: "active" } - 已有全量索引？删掉它再建 partial，否则查询优化器可能仍选旧索引（尤其当
status区分度低时）
所有读操作必须显式带上 status: "active" 条件
加了 status 字段不等于自动生效——MongoDB 不会替你过滤。漏写条件是线上最常见的逻辑删除失效原因。
-
findOne({ _id: ObjectId("...") })→ 必须改成findOne({ _id: ObjectId("..."), status: "active" }) -
countDocuments({ userId: 123 })→ 得写成countDocuments({ userId: 123, status: "active" })，否则统计虚高 - 聚合管道里，
$match阶段必须放在最前，且含status: "active"；否则后续$lookup或$group可能引入已删数据 - 使用 ODM（如 Mongoose）时，别依赖中间件自动注入——检查每个
.find()调用点，特别是历史遗留代码和聚合调用
硬删前务必确认无残留引用，尤其在关联集合中
逻辑删除只是标记，不代表数据真正安全。如果某天你要清理过期的 status: "deleted" 文档，物理删除前得确保：
- 没有其他集合通过
refId字段引用这些文档（例如日志、审计、关系表） - 应用层所有缓存（Redis、本地缓存）已失效，否则可能返回已删数据
- 备份策略是否包含这些“已删但未清”的文档？归档脚本是否跳过它们？
- 真正执行
deleteMany({ status: "deleted", deletedAt: { $lt: ISODate("...") } })前，先用explain()看是否命中 partial index，避免全表扫描
最麻烦的从来不是加个字段或建个索引，而是让所有查询路径都意识到：这个文档的“存在性”是有上下文的，不是靠 _id 就能认定它可读。
