MongoDB事务中乐观锁并发控制及版本号校验

先说几个核心判断：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 都拿不到。