Firebase Firestore多文档同时上传最优方案咨询（iOS应用场景）

最优方案推荐 #

结合你的业务场景，优先选择优化后的方案2，安全性、可维护性的收益远高于额外的Cloud Functions成本，你担心的触发器重复触发问题也有成熟的低成本解法可以完全规避。

三个方案的多维度对比 #

安全性 #

• 方案1风险最高：需要开放用户B的文档写入权限给任意登录用户，很容易被恶意调用批量刷写用户B的保存/关注列表，甚至篡改其他字段，对应的安全规则逻辑非常繁琐，稍有疏漏就会出现数据安全事故。
• 方案2安全性最高：客户端仅需要操作自身的私有文档，安全规则只需要配置仅用户本人可写入自己的保存记录即可，逻辑简单几乎不会出现漏洞，其余写入操作全部在服务端执行，不会被客户端篡改。
• 方案3安全性中等：计数器在客户端更新同样需要开放计数器字段的写入权限，依然存在被恶意刷数的风险，表现优于方案1但远不如方案2可靠。

效率 #

• 方案1客户端感知的写入速度最快，但批量操作只要有一个环节失败就会全部回滚，比如用户B的文档刚好处于写入限制状态，会导致用户A的保存操作完全失败，用户体验较差。
• 方案2实际用户体验最好：客户端仅需上传单条极小的保存记录即可收到成功反馈，不需要等待所有操作完成，服务端操作为异步执行，仅用户B侧的列表更新会存在最多几百毫秒的滞后，对业务几乎无影响。
• 方案3客户端需要写入两个字段，耗时略高于方案2，同样存在批量操作失败的风险。

成本 #

• 方案1直接成本最低，无Cloud Functions调用费用，但后续如果出现安全问题、需要修复脏数据的隐性成本极高。
• 方案2额外产生的成本极低：Firebase Cloud Functions免费额度为每月200万次调用，超出后每100万次调用仅收费0.4美元，即使是十万日活的应用，每月这部分成本也不会超过10美元，几乎可以忽略。
• 方案3成本介于两者之间，没有明显优势。

触发器重复触发问题的解决方案 #

你担心的.onWrite重复触发属于Firebase触发器的「至少一次交付」机制，通过两个简单手段即可完全规避：

1. 用onCreate触发器代替onWrite：保存记录属于新增操作，onCreate仅会在文档首次创建时触发，本身触发场景就远少于onWrite。
2. 增加幂等判断逻辑：在用户A的保存记录中新增一个is_processed布尔字段，触发器执行完所有关联操作后将该字段设为true，每次触发器触发时先校验该字段，若已为true则直接退出，不会重复执行逻辑。
   计数器累加直接使用Firestore内置的FieldValue.increment(1)原子方法，即使出现极端重复触发场景也不会出现计数错误。

内容的提问来源于stack exchange，提问作者Nicolò Padovan