Firestore不同集合复用文档ID是否可行？存在哪些弊端？

先说核心结论：这种做法本身没有本质性的技术弊端，但要留意几个潜在的实践风险：

• 数据一致性隐患
  不同集合的文档是完全独立的，你得保证ID复用的操作是原子性的——比如用Firebase的批量写入或事务。如果中间出问题（比如网络断了），可能会出现一个集合有文档、另一个没有的情况，导致数据不一致。比如savedGamesFull创建成功，但savedGamesLight写入失败，后续用这个ID查询时就会出现缺失。

• 权限控制容易踩坑
  Firestore的安全规则是按集合粒度配置的。如果不同集合用相同ID，比如存私密数据的players和存公开数据的playerPublicProfiles，写规则时得格外小心，不能因为ID相同就混淆权限逻辑。比如不小心把players的私密规则套到playerPublicProfiles上，会直接泄露敏感数据；反之则会导致公开数据无法正常访问。

• 后期维护易混淆
  项目规模变大、新人加入时，相同ID的复用可能会让开发者误以为这些集合的文档是关联的子集合或有内置关联，但实际上它们只是手动维护的并行文档。这种认知偏差可能会导致错误的查询逻辑，比如误把不同集合的同ID文档当成同一数据的不同部分，忽略了它们是独立存储的事实。

• 关于热点问题（Hotspotting）
  你担心的热点问题确实和这种场景无关。Firestore的热点主要是大量请求集中在同一个文档、同一集合的前缀范围或同一个分区。而不同集合的同ID属于完全不同的存储路径（比如players/{id}和playerStats/{id}是两个独立路径），不会触发热点问题。

优化建议 #

• 用批量写入（batch()）或事务来确保多集合文档的创建/更新操作原子性，避免数据不一致。
• 写安全规则时明确区分不同集合的权限逻辑，不要依赖ID关联性简化规则。
• 在团队文档或注释里明确说明这种ID复用的设计逻辑，避免后续维护混乱。

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