先说几个核心判断：findOneAndUpdate 本身并不开启事务，但通过在 filter 中显式匹配 version 字段，并配合 $inc 进行原子更新，就能实现单文档级别的乐观锁。而 matchedCount === 0 是版本冲突的唯一可靠信号，一旦出现，就必须重试并重新读取最新文档。
特别要提醒一点：别在事务里硬套乐观锁——这俩根本不是一回事，硬凑反而会让并发性能更差。
findOneAndUpdate 带 version 条件 ≠ 事务
MongoDB 的 findOneAndUpdate 本身不开启事务，也不加锁，但它天然具备单文档原子性。你写 { _id: docId, version: 5 } 并配合 $inc: { version: 1 }，MongoDB 就会把「检查旧 version 是否还存在」和「升版+更新业务字段」打包成一次原子写操作。事务在这里纯属冗余：事务会在 WiredTiger 层对文档加写锁，高并发下容易排队、拖慢吞吐，甚至触发 write conflict 错误导致自动中止。
真正起作用的，不是包裹一层 session.startTransaction()，而是 filter 中显式带上 version 字段匹配。这才是乐观锁的生命力所在。
updateOne + version 校验失败时 matchedCount === 0 才是正牌信号
很多人用 updateOne 后只看 modifiedCount 或 result.value === null，这其实不太靠谱：
modifiedCount只表示“字段值真变了”。比如你$set: { status: 'done' }，但 status 原来就是 'done'，那么它就会返回 0 —— 但这跟版本冲突毫无关系。result.value是findOneAndUpdate特有的返回字段，updateOne根本不返回它。- 唯一能确认“我读到的状态是否还有效”的，是
result.matchedCount === 0。
当这个值为 0 时，说明在你读出 version 之后、发起 update 之前，该文档已被别人更新，version 不再匹配。此时必须重试，绝不能跳过。
重试逻辑里最容易漏掉的三件事
很多人写了 while 循环 retry，结果线上还是丢更新。那问题出在哪儿？不是 retry 本身，而是上下文没重置干净：
- 每次重试前必须重新
findOne拿最新文档，不能复用第一次读出的version和业务字段——否则你是在拿过期快照反复撞墙。 - 如果更新前调了外部服务（如发信息、扣第三方账户），得确保这些操作是幂等的；否则重试会重复扣款、重复发通知。
- 别只检查
matchedCount === 0，还要捕获result.lastErrorObject?.code === 11000（唯一键冲突），它可能和乐观锁失败同时发生。
version 字段初始化和类型必须严格
version 不是装饰字段，它是乐观锁的命门：
- 插入首条文档时，必须显式设置
version: 0或version: 1，不能留null、undefined或空字符串——否则后续所有$eq匹配都会失效。 version必须是数字（NumberInt或NumberLong），不能是字符串"1"或ObjectId。字符串比较在 BSON 里是字典序，"10"<"2"会导致逻辑错乱。- 千万别在
$set里手动赋值version: 2——这绕过了原子性，且并发写可能把别人刚升的 2 覆盖回去。
最常被忽略的其实是驱动行为：Node.js Driver 4.x+ 默认 returnDocument: 'before'，你要显式设为 'after' 才能拿到升版后的最新快照。这个细节不处理，重试时连最新 version 都拿不到。
