Firebase项目Firestore短数字ID生成方案是否存在性能风险？

结论：你的当前方案完全可用，无需重构 #

你在补充说明里的判断完全正确：Firestore的热点问题仅出现在连续递增/递减的顺序ID场景下，你的随机生成6位数字ID的逻辑不会触发该风险。

具体原因 #

Firestore会自动将文档按照ID的范围拆分到不同的存储节点，以实现负载均衡。如果使用连续顺序ID，所有新写入的文档都会集中在ID范围的尾部，导致单个节点持续承受高负载，才会出现热点问题。
你的实现生成的是完全随机的6位数字，ID会均匀分布在000000到999999的整个ID空间内，写入请求会自动分散到不同的存储节点，完全符合Firestore的最佳实践要求。

规模适配性 #

如果你的集合规模始终在数千条的量级：

• 完全不存在性能损耗，ID冲突的概率也极低（千分之一以下）
• 当前3次重试的逻辑完全可以覆盖冲突场景，几乎不会出现生成失败的情况

可选优化建议（非必需） #

如果后续业务规模增长到十万条以上，可以做两个小调整提升稳定性：

• 将重试次数从3次调整为5次，降低高冲突概率下的生成失败率
• 可以在写入前先调用get()方法判断ID是否存在，再执行创建操作，减少异常写入的错误日志产生

你提供的实现代码 #

const generateUniqueId = async (parentId, tries = 1) => {
    try {
        if (tries > 3) return false;

        const zeroPad = (num, places) => String(num).padStart(places, '0');
        const id = zeroPad(Math.floor(Math.random() * 999999), 6);

        await DB.collection('parent')
            .doc(parentId)
            .collection('child')
            .doc(id)
            .create({ id });

        return id;
    } catch (error) {
        if (error.code === 6) {
            return await generateUniqueId(parentId, tries + 1);
        } else {
            return false;
        }
    }
};

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