findOneAndUpdate是唯一可靠选择，因其在WiredTiger中对匹配文档加锁，将“查+改+返回”压缩至单次原子操作；而先find再updateOne存在竞态窗口，且模糊查询条件在分片集群中不可靠。
必须用 findOneAndUpdate，其他方式（包括先 find 再 updateOne）无法保证原子性。
为什么 findOneAndUpdate 是唯一可靠选择
MongoDB 的文档级原子性只在单次写入操作内生效。findOneAndUpdate 在 WiredTiger 存储引擎中对匹配文档加锁，整个“查 + 改 + 返回”在一个网络往返和一次锁持有周期内完成。而分开调用 find 和 updateOne 之间存在时间窗口：两个并发请求可能同时读到旧值，各自计算新值后写入，最终只有一方结果保留——典型竞态。
常见错误现象：
- 订单状态从
"pending"更新为"processing"，但高并发下多个请求都成功返回"processing"，实际只应有一个被处理 - 库存扣减时出现负数，因多个请求读到相同剩余量后都执行了
$inc: { stock: -1 }
查询条件必须带唯一约束，否则行为不可靠
即使操作成功返回，若查询条件不指向唯一文档，就无法保证你拿到的是“被更新的那个”——尤其在分片集群中，findOneAndUpdate 要求路由能精准定位到一个分片，模糊条件（如 { status: "pending" }）会被拒绝或返回未定义结果。
安全写法：
-
{ _id: ObjectId("...") }—— 总是安全 -
{ orderNo: "ORD-20260907-123" }—— 前提是orderNo字段建了唯一索引
危险写法：
-
{ tags: "urgent" }—— 可能匹配多条，只改第一条，顺序不可控 -
{ createdAt: { $lt: new Date() } }—— 无索引时性能差，有索引也不保证唯一
returnDocument 和 upsert 的关键细节
returnDocument: "after" 确保返回的是更新后的完整文档；returnDocument: "before" 仍会执行更新，只是返回旧快照——这点常被误认为“没更新”。
upsert: true 需格外谨慎：
- 当查询无匹配时，MongoDB 会插入一条新文档，但插入内容**仅包含
update参数里的字段**，不自动带上查询条件中的字段 - 例如：
findOneAndUpdate({ userId: 123, type: "settings" }, { $set: { theme: "dark" } }, { upsert: true })插入的文档里没有userId和type字段，只有{ theme: "dark" } - 正确做法是显式用
$setOnInsert补全：{ $set: { theme: "dark" }, $setOnInsert: { userId: 123, type: "settings" } }
嵌入式结构更适合原子更新，别硬套关系型思路
如果业务逻辑涉及多个关联字段（比如购物车里商品数量 + 总价 + 修改时间），把它们放在同一文档内，用 findOneAndUpdate 一次性更新，比拆成多个集合+事务更轻量、更可靠。
容易被忽略的一点：事务虽支持跨文档，但开销大、有超时限制（默认 60 秒），且分片集群中需额外配置 writeConcern。绝大多数场景下，与其强上事务，不如重构数据模型——把强关联字段嵌入同一文档，让单文档原子性兜底。
