服务器端Firestore客户端能否通过Version字段实现乐观锁？

完全可以通过给文档添加Version字段实现乐观锁，这是Firestore中常用的自定义并发控制方案，适合不想依赖内置事务逻辑的场景。

具体实现步骤 #

• 给目标文档添加一个version字段（建议用整数类型，初始值设为0）
• 更新流程：
  1. 先读取目标文档，获取当前的version值
  2. 构造更新请求，同时更新业务字段和version（将版本号+1）
  3. 用条件更新限定只有当文档的version等于读取到的当前值时，才执行更新
  4. 检查更新结果的写入计数：如果计数为0，说明有并发冲突（文档已被其他请求修改）；计数为1则更新成功

代码示例（Node.js） #

async function updateWithOptimisticLock(docRef, updateData) {
  // 读取当前文档及版本
  const docSnap = await docRef.get();
  if (!docSnap.exists) throw new Error("目标文档不存在");
  
  const currentVersion = docSnap.data().version;

  // 执行带版本条件的原子更新
  const updateResult = await docRef.update(
    {
      ...updateData,
      version: currentVersion + 1
    },
    { where: ["version", "==", currentVersion] }
  );

  // 检测并发冲突
  if (updateResult.writeCount === 0) {
    throw new Error("并发冲突：文档已被其他请求修改，请重试");
  }

  return updateResult;
}

和Firestore内置事务的对比 #

• 内置事务（悲观锁）：Firestore服务器端库会锁定目标文档直到事务完成，适合冲突频繁、需要强一致性的场景，但可能带来更高的延迟和资源占用
• 自定义乐观锁：不锁定文档，依赖客户端先读后写+条件判断，性能开销更小，适合冲突频率较低的场景，但需要自行处理冲突重试逻辑

注意事项 #

• 必须保证业务字段和version的更新是原子操作，不能分开执行
• 冲突发生时，建议实现指数退避的重试机制，或者返回错误让客户端处理
• 高并发场景下，乐观锁可能导致较多重试，此时内置事务可能是更优选择

内容的提问来源于stack exchange，提问作者Robert Mihai