不能直接用 deleteOne() 做逻辑删除，因为其执行的是物理删除，数据彻底丢失，无法审计或恢复；软删除必须通过 is_deleted 字段标记并配合查询过滤实现。
为什么不能直接用 deleteOne() 做逻辑删除
因为一旦调用 deleteOne() 或 remove()，数据就从磁盘上消失了，无法回溯、审计或恢复。软删除本质是“标记为已删除”，靠查询时过滤实现行为隔离。硬删之后再加 is_deleted: true 字段毫无意义——字段都不存在了。
常见错误是：先删库再补字段，或者在业务代码里漏掉对 is_deleted 的检查，导致前端仍能查到“已删除”数据。
- 所有读操作（
find()、findOne()、聚合管道）必须显式排除{ is_deleted: true } - 写操作（
updateOne()、replaceOne()）不能覆盖掉is_deleted字段，否则可能误复活已删数据 - 避免在 schema 默认值里设
is_deleted: false—— 某些 ODM（如 Mongoose）会把未传字段自动补默认值，导致更新时意外清空该字段
如何安全地添加 is_deleted 字段并建索引
已有集合加字段不能只靠应用层写入，得考虑存量数据一致性。最稳妥方式是分三步走：
- 先给集合加一个稀疏索引：
db.collection.createIndex({ is_deleted: 1 }, { sparse: true })—— 稀疏索引跳过is_deleted不存在的文档，避免全量扫描时拖慢查询 - 用
updateMany()补全历史数据：db.collection.updateMany({ is_deleted: { $exists: false } }, { $set: { is_deleted: false } }) - 再把索引改成非稀疏（可选）：
db.collection.dropIndex("is_deleted_1")后重建普通索引，方便后续countDocuments({ is_deleted: true })统计准确
注意：如果集合很大，updateMany() 可能锁表或超时，建议在低峰期执行，或分批处理（用 _id 范围 + limit 循环）。
查询时漏掉 is_deleted: false 会导致什么
最直接后果是用户看到“已被删除”的内容，比如订单列表里出现状态为“已取消”但实际标记为 is_deleted: true 的订单。这不是 UI 层能兜住的问题，是数据访问层契约失效。
典型场景包括：
- 聚合管道中没在
$match阶段过滤，导致$lookup关联出已删文档 - 使用
findOneAndUpdate()更新前未校验目标文档是否存活，结果把已删记录又“改活”了 - 管理员后台导出全量数据时，忘了加
{ is_deleted: { $ne: true } }，导出含敏感已删信息
建议在 DAO 层封装统一的“活跃文档查询”方法，例如 findActive() 内部自动追加 { is_deleted: false } 条件，而非每个业务点手写。
is_deleted 字段类型和性能影响
必须用布尔值（Boolean），别用字符串 "true" 或数字 1。MongoDB 对布尔字段的索引效率高，且 { is_deleted: true } 查询能命中索引；而 { is_deleted: "true" } 会绕过索引，变成 collection scan。
索引本身有轻微写开销（每次插入/更新都需维护索引项），但相比软删除带来的审计、合规、误操作恢复价值，这点代价可接受。真正要注意的是：不要给 is_deleted 单独建冗余复合索引（如 { status: 1, is_deleted: 1 }）却忽略查询模式——如果绝大多数查询都带 status 和 is_deleted，那这个复合索引合理；如果只是偶尔加 is_deleted，单独的 { is_deleted: 1 } 更轻量。
还有一个容易被忽略的点：TTL 索引不能和软删除混用。TTL 依赖日期字段自动删文档，跟软删除语义冲突；真要清理历史软删数据，得自己写定时任务查 { is_deleted: true, deleted_at: { $lt: ... } } 后调用 deleteMany()。
