Firestore Cloud Functions的onCreate/onDelete偶发重复触发问题咨询

嗨，这个问题我碰到过好几次了——Firestore触发器偶发重复触发同一份文档，而且不是每次都出现，确实容易让人摸不着头脑。其实核心原因大多和云函数的交付语义、Firestore的内部机制有关，给你梳理几个最常见的点：

1. 云函数的「至少一次」交付设计（最核心原因） #

Google Cloud Functions（包括Firebase绑定的触发器）本身就是至少一次的交付语义，不是「恰好一次」。也就是说，当你的函数执行超时、网络波动、或者Google内部服务临时故障时，系统会自动重试同一个事件——哪怕你的文档只被创建/删除了一次。这个是官方设计的一部分，不是bug，很多开发者一开始都会忽略这点。

2. 触发器部署的衔接问题 #

如果短时间内多次部署同一个触发器（比如频繁改代码重新部署），可能会出现旧的触发器实例还没完全销毁，新的实例已经上线的情况。这时候同一个事件可能会被新旧两个实例同时捕获，导致重复执行。

3. 事务/批量写入的隐性重试 #

如果你的文档是通过Firestore事务或者批量写入操作创建/删除的，事务本身有重试机制（比如遇到并发冲突时）。虽然事务最终只会提交一次成功的写操作，但有时候重试过程中可能会触发多次触发器事件——不过这种情况比较少见，大多还是和第一条的重试有关。

怎么解决？必须实现幂等性 #

既然重复触发是设计预期内的情况，那解决的核心就是让你的触发器函数具备幂等性——也就是重复执行多次，结果和执行一次完全一样。这里给你几个实用的实现方式：

• 用事件ID去重：每个触发器事件都会携带一个唯一的eventId，你可以把这个ID存在Firestore（或者Redis这类缓存）里，每次执行函数前先检查这个ID是否已经被处理过，如果是就直接返回成功，不再执行后续逻辑。
• 给文档加处理标记：比如在处理前，先通过事务给目标文档添加一个processed: true的字段（或者processing状态），如果查询到这个标记已经存在，就直接跳过处理。
• 原子化操作：把你的处理逻辑包装在Firestore事务里，确保操作要么完全成功，要么完全失败，避免重复执行产生中间状态。

举个简单的例子，用事件ID去重的Node.js代码片段：

exports.myTrigger = functions.firestore.document('col/{docId}').onCreate(async (snap, context) => {
  const eventId = context.eventId;
  const firestore = admin.firestore();
  
  // 检查这个事件是否已经处理过
  const eventRef = firestore.collection('processedEvents').doc(eventId);
  const eventSnap = await eventRef.get();
  
  if (eventSnap.exists) {
    console.log('事件已处理，跳过');
    return null;
  }
  
  // 执行你的业务逻辑
  // ...
  
  // 标记事件已处理
  await eventRef.set({ processedAt: admin.firestore.FieldValue.serverTimestamp() });
  return null;
});

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