Cloud Firestore触发器重复执行：数组长度校验是否足够？

结论：你的校验代码没法防止重复执行 #

你写的这段判断逻辑是对比触发事件里change.before和change.after的数组长度，但Firestore触发器的重复触发，指的是同一个事件被多次推送给函数——也就是说每次重复调用时，change.before和change.after的快照内容完全一样（比如都是数组从99条变成100条的那个快照）。这时候你的判断条件永远不成立，代码该跑还是会跑，根本起不到拦截重复执行的作用。

为什么你的场景必须做幂等处理？ #

你的逻辑是“数组满100条就清空并处理数据”，如果重复执行，会出两个核心问题：

• 同一批数据被多次处理（第一次处理已经把数组清空了，但重复触发的事件还是基于“数组有100条”的旧快照，函数可能会再次读取这批旧数据来处理）
• 虽然重复清空数组影响不大，但数据重复处理会导致业务逻辑混乱（比如重复生成报表、重复发送通知等）

靠谱的幂等实现方法 #

方法1：读取文档最新状态判断 #

别依赖触发事件的快照，函数执行时直接读文档当前的真实状态：

const docRef = change.after.ref;
const currentDoc = await docRef.get();
const currentArray = currentDoc.data().array;

// 如果当前数组长度不是100（说明已经被处理过），直接返回
if (currentArray.length !== 100) {
  return;
}

// 执行清空和数据处理
await docRef.update({ array: [] });
// 这里写处理数据的代码...

这样就算旧事件重复触发，只要第一次处理已经把数组清空，后续调用读到的当前数组长度是0，就会直接跳过处理。

方法2：加个处理状态标记（更稳妥） #

给文档加个isProcessed布尔字段，用Firestore事务来确保判断和更新的原子性：

const docRef = change.after.ref;

await db.runTransaction(async (transaction) => {
  const doc = await transaction.get(docRef);
  const array = doc.data().array;
  const isProcessed = doc.data().isProcessed || false;

  // 数组没满100，或者已经处理过，直接结束
  if (array.length !== 100 || isProcessed) {
    return;
  }

  // 标记为已处理，同时清空数组
  transaction.update(docRef, {
    array: [],
    isProcessed: true
  });

  // 这里写处理数据的代码...
});

// 如果之后还要继续收集数据，可以在处理完后把isProcessed改回false

这种方式能搞定并发场景下的重复问题，因为事务会保证只有第一个执行的请求能完成更新，后续请求一看到isProcessed是true，就直接跳过了。

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