怎么在MongoDB中实现乐观锁？基于版本号字段的条件更新
为什么 updateOne 加 $eq 版本号检查不等于乐观锁
很多开发者容易掉进一个思维陷阱：直接在 updateOne 的查询条件里写上 { version: { $eq: 1 } }，就以为万事大吉，能防止数据被覆盖了。其实，这个做法漏掉了一个关键环节：它并没有保证你“读出的那个 version 值，就是当前数据库里的最新值”。
想象一下这个场景：你先读到 version 是 1，然后开始处理业务逻辑。就在这个空档，另一个操作已经悄悄把 version 更新到了 2。此时，你仍然拿着旧的版本号 1 去执行更新，结果居然还能匹配成功。这哪里是乐观锁？这分明是一个典型的条件竞态漏洞，误判了更新状态。
所以，真正靠谱的做法，必须把“读取版本号”和“更新校验”这两个动作，串成一个原子操作。这得依赖 MongoDB 单文档写操作的天然原子性来兜底。具体流程应该是：
- 先用
findOne取出文档及其当前的version值。 - 业务逻辑处理完毕后，在
updateOne中一次性完成两件事：检查version是否未变，同时将version自增。 - 最后，必须检查
result.matchedCount === 1才意味着更新成功，否则就得走重试或者报错流程。
如何用 $set 和 $inc 一次完成版本校验与自增
这里有个技术细节需要注意：MongoDB 的更新操作，不允许在查询条件里直接引用原字段值做动态比较（比如写成 { version: oldVersion } 这种变量形式）。但是，我们可以巧妙地利用 $eq 操作符配合 $inc 运算符，在单次写入中完成校验和版本号递增，从而杜绝中间状态被篡改的可能。
来看一个 Node.js 驱动下的示例代码：
const result = await collection.updateOne(
{ _id: docId, version: 5 },
{
$set: { updatedAt: new Date(), /* 其他需要更新的字段 */ },
$inc: { version: 1 }
}
);
这里有几点需要特别提醒：
version字段务必使用数字类型（如 Integer），字符串或者 ObjectId 是无法进行$inc操作的。- 查询条件里的
version: 5，应该是你上一步findOne读到的确切值，而不是一个硬编码的数字。 - 如果返回结果的
matchedCount为 0，那就清晰表明，在你读取之后、更新之前，这条数据已经被别人修改过了，你的本次操作自动失效。 - 切忌在
$set阶段再次设置version: 6。这样做不仅绕过了原子递增的保护，而且在并发写入时极有可能导致版本号被意外覆盖。
为什么不用 findAndModify 或事务替代
你可能会想，findAndModify 命令能原子性地返回修改前的文档，是不是更合适？实际上，它依然没有解决核心问题：你仍然需要自己手动去比对版本号。况且，它的原子性仅限于单个文档内部，无法嵌入更复杂的业务逻辑判断。
至于启用多文档事务，那更是杀鸡用牛刀了。乐观锁的设计初衷，就是为了避免数据库层面的锁表开销。如果仅仅为了一个版本号检查就去开启事务，反而会引入写锁，增加性能损耗，得不偿失。
更务实的方案选择是：
- 对于绝大多数单文档更新场景，坚持使用带
version条件的updateOne。它足够轻量、快速，并且兼容所有 MongoDB 版本。 - 如果需要跨多个文档保持强一致性，那其实已经超出了乐观锁的典型应用范围。这时候，应该考虑在业务层做补偿，或者接受最终一致性方案。
- 如果一个文档频繁发生更新冲突（比如每秒被多次争抢修改），那很可能不是技术选型问题，而是数据模型设计需要反思——要么拆分数据粒度，要么就该考虑引入分布式锁了。
容易被忽略的初始化和边界问题
乐观锁机制要顺利运转，初始化工作不能马虎。在第一次插入文档时，必须显式地将 version 字段设为 0 或 1null。否则，后续所有基于 $eq 的匹配都会失败。
另外，不同驱动程序的行为细节也值得留意：
- MongoDB Node.js Driver 从 v4 版本开始，默认启用
strict模式，undefined字段不会被发送到数据库，但null会。因此，统一用0来初始化版本字段是最稳妥的。 - 如果使用 Mongoose ODM，记得关闭其默认的
versionKey选项（即设置versionKey: false），否则它会自动管理一个__v字段，干扰你自己的版本控制逻辑。 - 客户端时间不同步不会影响 version 机制，但请注意：绝对不要用
updatedAt这类时间戳字段作为版本依据——它们既不具备可比性，也无法原子递增。
最后，关于索引：version 字段本身不建索引也可以工作。但如果你的查询条件中频繁同时使用 _id 和 version，那么为 { _id: 1, version: 1 } 建立一个复合索引，可以有效避免全表扫描，提升查询效率。
