如何在Firestore事务中添加文档？寻求替代GUID的解决方案

这个问题我之前帮不少开发者捋过思路，确实Firestore事务里没法直接用自动生成ID的add()方法——毕竟事务重试机制下，重复执行add()会生成多个不同ID的文档，完全破坏了事务的原子性要求。至于你担心GUID作为ID导致索引过长的问题，其实有几个更优的替代方案：

1. 利用事务内计数器生成确定性ID #

你可以在Firestore中维护一个专门的计数器文档（比如counters/orderCounter），在事务内完成「读取计数器→递增→用新值做文档ID」的闭环操作。因为事务是原子执行的，即使重试，整个逻辑会重新跑一遍，最终只会生成一个唯一的、短格式的ID，完全不用担心索引长度问题。

示例代码（JavaScript）：

db.runTransaction(async (transaction) => {
  const counterRef = db.collection('counters').doc('orderCounter');
  const counterDoc = await transaction.get(counterRef);

  let newId;
  if (!counterDoc.exists) {
    // 初始化计数器
    await transaction.set(counterRef, { value: 1 });
    newId = '1';
  } else {
    newId = (counterDoc.data().value + 1).toString();
    await transaction.update(counterRef, { value: parseInt(newId) });
  }

  // 用生成的ID创建目标文档
  const targetDocRef = db.collection('yourCollection').doc(newId);
  await transaction.set(targetDocRef, { /* 你的文档数据 */ });
});

2. 用业务唯一标识作为文档ID #

如果你的业务场景里有天然的唯一标识（比如用户邮箱、订单的业务编号，或者多个字段的组合值），直接把它当作文档ID是最省心的方案。既不需要额外维护计数器，ID长度也完全可控，对索引非常友好。

比如创建用户文档时，用邮箱作为ID（确保邮箱在业务层唯一）：

db.runTransaction(async (transaction) => {
  const userEmail = 'user@example.com';
  const userRef = db.collection('users').doc(userEmail);
  const existingUser = await transaction.get(userRef);

  if (existingUser.exists) {
    throw new Error('该用户已存在');
  }

  await transaction.set(userRef, {
    email: userEmail,
    username: 'exampleUser',
    // 其他用户数据
  });
});

3. 退而求其次：优化GUID的使用 #

如果实在找不到合适的业务标识或计数器方案，使用GUID也并非不可行——Firestore对字符串索引的长度容忍度很高，官方自动生成的文档ID本质也是Base64编码的GUID变体，不会对性能造成明显影响。

如果担心单字段索引效率，可以通过复合索引优化查询：比如把GUID和常用查询字段（如userId、createTime）组合创建复合索引，避免单独依赖GUID的单字段索引。

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