findOneAndDelete 能保证原子性，因其是 MongoDB 服务端原生命令，通过 findAndModify（remove: true）在单次请求中完成查删，加文档级锁并返回删除前快照；不支持跨分片非路由查询，需索引优化，且仅限整文档操作。
findOneAndDelete 为什么能保证原子性
因为它是 MongoDB 服务端原生命令，整个“查 + 删”在单次请求中由 mongod 一次性完成，不会被其他操作插入或干扰。不是客户端先 findOne 再 deleteOne 那种两步走——那根本不算原子操作，中间可能已被别的写入改掉数据。
- 底层调用的是
findAndModify命令（带remove: true），服务端加行级锁（WiredTiger 引擎下是文档级锁） - 返回值里一定包含被删文档的快照（
value字段），哪怕它刚被另一个线程更新过，你也拿到的是删除那一刻的真实状态 - 不支持跨分片事务语义下的原子性；如果集合启用了分片且查询条件没命中单一 shard，会报错
Cannot use findAndModify with a sharded collection that does not have a shard key in the query
必须带 _id 或唯一索引字段才能高效执行
没有合适索引时，findOneAndDelete 会触发全表扫描，不仅慢，还可能因锁住大量文档引发阻塞。尤其在高并发删单条场景下，性能和稳定性直接受影响。
- 最佳实践：查询条件里至少包含
_id，或已建好前缀匹配的复合索引（如{ status: 1, createdAt: -1 }，查询用{ status: "pending" }就能命中） - 别用
{ tags: { $in: [...] } }这类低选择性条件直接删，除非你确认该字段有稀疏索引或值分布极不均匀 - 注意：即使有索引，若查询条件含
$regex开头通配（如^abc可走索引，但abc$不行），依然无法高效定位
返回结果里的 value 是删前快照，不是删后状态
很多人误以为 value 是“删完之后的数据”，其实它就是匹配到的原始文档——哪怕你删完立刻去 findOne 已查不到，value 仍是你删的那个。
- 示例：执行
db.orders.findOneAndDelete({ _id: ObjectId("..."), status: "draft" })，返回{ value: { _id: ..., status: "draft", amount: 99 } }——这个amount是删之前存的值 - 如果你依赖返回值做后续逻辑（比如发通知、记日志），得清楚它反映的是“删了什么”，而不是“删成什么样”
- 如果想确认是否真删成功，看
lastErrorObject.n是否为 1，或者直接检查value是否为null（没匹配到就返回null）
与 deleteOne 的关键区别：不只删，还必须返回删掉的文档
deleteOne 只返回操作结果（{ acknowledged: true, deletedCount: 1 }），而 findOneAndDelete 多一步把文档内容也捞出来。这多出来的 IO 和内存拷贝，在大数据量或大文档场景下会有可测差异。
- 吞吐敏感场景（比如每秒删几千条小订单）：优先用
deleteOne，再单独查（如果真需要内容） - 业务强依赖“删了谁”的上下文（比如风控系统要记录被删用户的完整 profile）：必须用
findOneAndDelete，避免两次网络往返和时间窗口问题 - 驱动层注意：
findOneAndDelete在 Node.js driver 中返回的是Promise，不是Promise<deleteresult></deleteresult>，别按deleteOne的结构去解构
$pull 更新，那不属于 findOneAndDelete 覆盖范围——它只处理整文档的查找与移除。 
