Firestore集合计数维护：onCreate触发函数与事务方案选型对比

第二种HTTPS可调用云函数方案的核心劣势 #

• 开发与改造成本高：原先客户端可直接通过Firestore SDK完成persons文档创建，兼容Firebase原生安全规则校验逻辑。切换方案后所有端的创建逻辑都要改造为调用云函数，还需要自行在云函数中实现参数校验、权限判断、异常捕获逻辑，很容易出现安全遗漏。
• 性能体验下降：直接写入Firestore走就近存储节点，延迟极低。HTTPS云函数会新增一层链路开销，尤其是低调用量场景下的函数冷启动概率很高，端侧感知到的写入延迟会明显上升。
• 一致性保障更复杂：onCreate触发器官方保证至少执行一次，后台会自动对执行失败的任务重试。而HTTPS云函数如果遇到端侧网络波动、调用超时，需要自行实现幂等重试逻辑，处理不当反而更容易出现persons文档和population计数不一致的问题。
• 维护成本高：切换后所有persons文档的创建都必须走该云函数入口，一旦后续有其他服务、管理后台绕过云函数直接操作Firestore，就会导致计数不准，需要额外加规则限制直接写入persons集合。

HTTPS可调用云函数的成本差异 #

两种方案的云函数计费维度都是调用次数、执行时长、内存占用，实际使用成本几乎没有差别：

• 两种方案都只会触发一次云函数调用
• 核心逻辑都是创建persons文档+对population执行FieldValue.increment(1)操作，执行时长和内存消耗基本一致

中小项目的调用量基本都能覆盖在Firebase免费配额内，不需要担心成本上升。

另外补充：官方触发器因为系统故障完全不执行的概率极低，远低于自行实现云函数逻辑出问题的概率。如果担心极端场景的一致性，可定期运行定时脚本，按城市分组统计persons集合的文档数，和cities集合的population字段做对比修正即可，远比重构整套写入逻辑的投入低。

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