成本角度：前端用updateDoc还是云函数更新Firestore时间戳更划算？

从成本和用户量增长后的账单影响来看，方案一（前端直接用updateDoc）的成本远低于方案二（云函数触发更新），具体分析如下：

成本拆解 #

方案一：前端updateDoc #

每次用户操作仅产生 1次Firestore写入操作——因为updateDoc同时修改elements和updated两个字段，属于单次写入请求，没有额外费用：

function addElement(element) {
  updateDoc(
    doc(firestore, 'customers', user.uid, 'collections', collection.id),
    {
      elements: arrayUnion(element),
      updated: new Date()
    }
  )
}

无云函数调用费、无额外读取/写入操作，成本完全可控。

方案二：云函数onDocumentUpdated #

这个方案的成本是叠加的，每触发一次至少包含：

1. 初始Firestore写入费：前端修改文档触发云函数的那次写入；
2. 云函数调用费：只要文档更新就会触发函数，哪怕你在函数里提前return null，依然会产生调用次数和执行时间的费用；
3. 额外Firestore写入费：当满足更新条件时，云函数执行set({merge: true})会再产生1次写入操作；
4. 潜在的重复触发成本：云函数更新updated字段后，会再次触发onDocumentUpdated事件，即使第二次函数直接返回，还是会多一次云函数调用费。

用户量增长后的账单影响 #

当用户量提升时，方案二的成本会呈线性甚至超线性增长：

• 每一次用户的文档修改都会触发云函数，调用次数和执行时间的费用会快速累积；
• 额外的Firestore写入操作会进一步拉高账单；
• 重复触发的问题会额外增加无意义的云函数调用。

而方案一的成本仅和用户的实际写入操作次数挂钩，没有额外冗余费用，账单增长更平缓，完全匹配用户操作的真实需求。

额外优势 #

方案一除了成本低，还更简洁：不需要部署、维护云函数，减少了后端复杂度，也避免了云函数冷启动、触发延迟等潜在问题。

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