如何判断Firestore带{merge:true}的set()调用是插入还是更新文档

带{merge: true}参数的set()方法没有任何公开、可稳定使用的返回值（包括所谓的隐藏返回字段）能直接标识本次操作是插入新文档还是更新已有文档。各端SDK返回的结果里只包含写入完成的时间戳确认，没有操作类型相关字段，不要尝试解析SDK内部未文档化的返回结构，版本迭代时随时可能失效，生产环境用风险极高。

不需要提前手动拉取文档判断存在性，下面两种方案都不会产生额外的读计费，同时能准确区分操作类型：

• 方案1：利用写操作自带的服务端前置校验
  Firestore的所有写操作都支持服务端原子前置校验，校验逻辑在写流程内完成，不会产生额外的文档读取开销，实现逻辑如下：
  1. 提前根据业务规则生成目标文档的固定ID（每日数据upsert场景一般用日期+业务唯一标识生成确定ID，天然符合要求）
  2. 先调用set(完整文档数据, { exists: false })，该操作会在服务端原子判断文档是否存在：
     • 调用成功：说明文档此前不存在，本次操作为插入新文档
     • 调用抛出「文档已存在」的错误：说明文档已存在，再调用set(待合并更新的字段, { merge: true, exists: true })即可，本次操作为更新已有文档
       整个流程的网络、计算成本和你之前直接调用set(merge:true)基本一致，也不存在并发覆盖问题。
• 方案2：内存缓存已处理ID（适合单次大批量处理场景）
  如果你是在短时间内集中处理批量每日数据，可以直接在进程内存里维护一个Set结构存储已经处理过的文档ID：第一次遇到某个文档ID时直接走插入逻辑，同时把ID存入缓存；后续再遇到同ID就走合并更新逻辑。这个方案连额外的网络校验开销都没有，性能最高，只要你的任务处理过程中没有其他客户端往对应集合写同ID文档，就不会出错。

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