mongodb可通过findoneandupdate原子操作实现乐观锁，关键是在单次命令中完成库存检查（stock > 0）、版本校验（version匹配）与扣减自增（$inc: {stock: -1, version: 1}），避免“先查后改”导致的竞态条件。
MongoDB 本身不支持传统关系型数据库中的 UPDATE ... WHERE version = ? 原子条件更新 + 自增版本号的乐观锁语义（如 MySQL 的 UPDATE ... SET version=version+1 WHERE id=? AND version=?），但可以通过 $inc、$min、findAndModify 或 findOneAndUpdate 配合原子操作与条件判断，模拟出等效的乐观并发控制。关键不是“有没有 version 字段”，而是“能否在一次原子操作中完成「检查库存是否充足」+「扣减」+「版本校验」三件事”。
为什么直接用 version 字段在 MongoDB 里容易失效
MongoDB 的文档更新是原子的，但「先查再更新」必然存在竞态窗口 —— 这和 MySQL 里不做 SELECT ... FOR UPDATE 是同一类问题。如果你写这样的代码：
const doc = await collection.findOne({ _id: id });
if (doc.stock > 0) {
await collection.updateOne({ _id: id }, { $set: { stock: doc.stock - 1 }, $inc: { version: 1 } });
}
这本质上仍是「读-改-写」三步，不是原子操作。高并发下多个请求同时读到 stock = 1，然后都执行 $set，最终变成 stock = 0 多次，导致超卖。
真正可用的路径只有一条：所有逻辑必须塞进单次 findOneAndUpdate 的 filter 和 update 中，让 MongoDB 引擎自己完成条件判断与变更。
用 findOneAndUpdate 实现库存扣减 + 版本校验原子操作
假设商品文档结构如下：
{
"_id": ObjectId("..."),
"sku": "A123",
"stock": 100,
"version": 1,
"status": "on"
}
正确做法是把库存检查、版本递增、扣减全部压进一个原子命令：
- 使用
$gt确保库存 > 0（比$gte 1更安全，避免负数残留） - 用
$inc: { stock: -1, version: 1 }同时扣减和升版 - 在
filter中带上version当前值，实现类似乐观锁的“预期版本匹配”
示例代码（Node.js + MongoDB Driver）：
const result = await collection.findOneAndUpdate(
{
_id: new ObjectId(productId),
stock: { $gt: 0 },
version: expectedVersion // 来自上一次查询，或从缓存读取
},
{
$inc: { stock: -1, version: 1 }
},
{ returnDocument: 'after' }
);
<p>if (!result.value) {
// null 表示没匹配到文档 → 库存不足 或 version 不匹配 → 超卖被拦截
throw new Error('stock_not_available_or_version_mismatch');
}
</p>
注意：expectedVersion 必须是客户端已知的“上一次成功读到的版本”，不能硬编码或忽略。如果业务允许无版本号兜底，可去掉 version 条件，仅靠 stock: { $gt: 0 } 保证不超卖，但会失去对「中间修改」的感知能力。
为什么不用 $set 而坚持用 $inc
$set: { stock: doc.stock - 1 } 要求你先读出当前 stock 值，这就又回到「读-改-写」的老路；而 $inc: { stock: -1 } 是服务端原子运算，MongoDB 在执行时会基于文档当前真实值计算，无需客户端参与数值计算。即使并发请求同时命中同一个文档，$inc 也会按顺序串行应用（底层由 WiredTiger 引擎保证），不会出现覆盖写。
同理，$inc: { version: 1 } 比 $set: { version: doc.version + 1 } 更可靠 —— 它不依赖客户端读到的 version 是否过期，只要 filter 中的 version 匹配成功，就说明该次更新是基于“那个版本”的上下文做的，否则整个操作失败。
实际部署时最容易被忽略的点
很多人以为加了 version 就万事大吉，但漏掉了三个硬性前提：
-
_id字段必须有索引（默认就有），否则findOneAndUpdate可能触发 collection scan，锁粒度升级为库级，性能崩盘 - 不要在事务外做任何依赖
stock值的业务判断（比如“库存 stock 是动态变化的，告警逻辑应基于变更后的结果文档，而非读取快照 - 如果用了分片集群，确保
_id是分片键或包含分片键，否则findOneAndUpdate无法路由到单一分片，将退化为广播操作，失去原子性保障
真正的难点不在语法，而在于把「业务逻辑收敛到单次原子命令」的思维转换 —— 所有分支判断、补偿动作、日志记录，都得放在命令成功/失败之后，而不是嵌套在“读取后 if-else”里。
