Firebase Firestore多用户并发更新文档数组避免覆盖的解决方案

并发写入数组的核心问题 #

当多个用户同时基于旧版本文档修改数组时，会出现丢失更新问题：后提交写入操作的用户会直接覆盖前一个用户的修改，最终只有最后一次写入的内容生效，先完成的更新会被完全抹除。
比如你提到的场景：文档初始数组为[1,2]，用户A、B先后读取到该版本，A要添加元素3，B要添加元素4；如果B先提交更新，数组变为[1,2,4]，随后A基于旧版本修改的[1,2,3]写回，就会直接覆盖B的修改，最终数组变为[1,2,3]，B的更新完全丢失。

保障数组更新一致性的可行方案 #

• 方案1：使用Firestore内置原子数组操作
  Firestore提供了服务端原子操作方法arrayUnion()和arrayRemove()，不需要客户端提前读取完整数组，直接将操作指令发送到服务端执行，服务端会基于当前最新版本的数组完成修改，天生支持并发场景。
  适用场景：仅需要添加指定元素（自动去重）、删除指定元素的简单操作，不需要修改数组内已有元素、不需要自定义数组处理逻辑。
  代码示例（Web端）：

  await db.collection("目标集合").doc("目标文档ID").update({
    数组字段名: firebase.firestore.FieldValue.arrayUnion("要添加的元素")
  });
  

• 方案2：使用乐观锁预条件检查
  读取文档时同步获取文档的updateTime更新时间戳，提交更新时增加预条件：仅当服务端当前文档的更新时间戳与你读取到的时间戳一致时，才允许更新。如果预条件不匹配（说明期间有其他人修改了文档），就重新读取最新版本的文档，修改后再次提交，直到更新成功。
  适用场景：需要对数组做自定义修改（比如修改指定下标元素、排序、过滤等），无法使用内置数组操作的场景。

• 方案3：使用Firestore事务处理
  将「读取文档获取数组→本地修改数组→写回文档」的整个逻辑放在Firestore事务中执行，事务天生具备原子性，且会自动检测冲突：如果事务执行过程中目标文档被其他用户修改，Firestore会自动重试事务，基于最新版本的文档重新执行修改逻辑，直到更新成功，不需要手动写重试逻辑。
  适用场景：复杂的数组修改场景，或者修改数组的同时还要更新文档内其他字段的场景。

示例场景的处理效果 #

如果使用上述任意一种方案处理：用户B先完成数组更新后，用户A的更新操作不会直接覆盖B的修改：

• 用arrayUnion的话，服务端会直接在B更新后的数组基础上添加A的元素，最终数组同时包含A、B添加的内容
• 用乐观锁/事务的话，A的更新会检测到文档已被修改，自动重新拉取最新版本的数组，修改后再提交，两人的更新都会保留，不会出现覆盖问题。

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