React.js+Firebase电商场景下分布式计数器分配订单号重复问题求助

你当前的代码逻辑存在竞态漏洞：分布式计数器的incrementBy和get是两个独立的非原子操作。当多个订单同时触发云函数时，会先后完成计数器+1写入，之后几乎同时调用get接口汇总所有分片的计数值，最终多个请求拿到的就是同一个数值，和分布式计数器本身的统计准确性无关，是操作时序导致的问题。

方案1：事务+单文档计数器（适合绝大多数中小商城） #

如果你的商城日订单量低于10万，完全不需要用分布式计数器，直接使用Firestore原生事务操作orders/stats文档的计数字段即可，事务天生保证读-改-写的原子性，100%不会出现重复订单号：

// 替换原有计数器相关代码
const statsRef = admin.firestore().collection("orders").doc("stats");
const orderNum = await admin.firestore().runTransaction(async transaction => {
  const statsDoc = await transaction.get(statsRef);
  const currentCount = statsDoc.exists ? (statsDoc.data().placed || 0) : 0;
  const newCount = currentCount + 1;
  // 原子更新计数和最新下单时间
  transaction.set(statsRef, {
    placed: newCount,
    lastOrdered: Date.now()
  }, { merge: true });
  return newCount;
});
// 后续直接使用orderNum即可，无需再单独更新stats文档的lastOrdered字段

单文档计数器每秒支持最高500次写入，对应每日最高支持4320万订单，完全满足普通电商的需求。

方案2：分布式计数器适配方案（适用于超大规模订单场景） #

如果确实需要使用分布式计数器应对极高并发的订单写入，可以改用号段预占逻辑：每次给计数器加100（可根据实际单量调整号段大小），当前批次的订单号从「上一次计数最大值+1」到「本次计数最大值」之间分配，号段用完后再申请下一段，完全避免并发竞态问题。

你当前代码中对同一个订单文档分两次调用update分别更新number和processed字段，可以合并为一次写入，减少数据库调用次数，降低运行成本和出错概率。

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