Cloud Firestore中Batch批量写入与Promise.all的差异对比

好问题！我来帮你捋清楚用Promise.all并行执行操作和Firestore Batch批量写入的核心区别，方便你根据场景选择合适的方式：

• 原子性保障
  这是最关键的差异：

  • Promise.all是并行发起多个独立的Firestore请求，这些操作彼此独立——哪怕其中一个失败，其他成功的操作依然会生效，不会回滚。
  • Batch写入是原子操作：所有操作会被打包成一个事务，要么全部成功执行，要么任何一个操作失败，所有操作都会回滚，数据回到初始状态。比如做转账这类需要强一致性的操作，Batch绝对是更安全的选择。

• 操作数量与请求效率

  • Batch有明确的上限：最多支持500个写入/更新/删除操作，所有操作会被打包成单个请求发送给Firestore，大大减少网络往返的开销。
  • Promise.all没有严格的操作数量限制，但每个操作都是独立的请求，当操作数量较多时，不仅会占用更多网络资源，还可能触发Firestore的并发请求限制，性能不如Batch高效。

• 操作类型支持

  • Batch只支持写入、更新、删除这类写操作，无法包含读取操作。
  • Promise.all的灵活性更高：你可以混合读写操作，甚至并行执行不同类型的Firestore操作（比如同时读多个文档+写多个文档）。如果你的逻辑需要先读取数据再执行写操作，Promise.all或者链式Promise会更适合。

• 错误处理逻辑

  • 使用Promise.all时，只要其中一个Promise被拒绝，整个Promise.all会立即抛出错误，但此时其他已经完成的操作已经生效了，你需要额外处理部分成功的情况，逻辑更复杂。
  • Batch的错误处理更简单：只有当batch.commit()执行时才会返回结果，失败的话所有操作都不会生效，你只需要处理这一次提交的结果即可。

场景建议 #

• 当你需要保证操作的一致性（比如订单创建、资金转移），或者有大量写操作需要高效执行时，优先用Batch。
• 当操作彼此独立、允许部分失败，或者需要混合读写操作时，选择Promise.all更合适。

内容的提问来源于stack exchange，提问作者J. Doe