管理客户端API密钥的合理Firestore架构应当如何设计？

1. API Key 作为文档ID的可行性 #

完全可行，且是适配你高频校验场景的最优选择：

• 你最核心的高频需求是通过API Key快速校验合法性，Firestore 按文档ID直接读取是O(1) 时间复杂度的操作，不需要额外建索引，性能拉满，同时能最小化读请求成本。
• 文档ID天然具备全局唯一性，可直接避免重复API Key的问题，不需要额外做去重逻辑。
• 安全优化建议：可对原始API Key做SHA256哈希后再作为文档ID存储，校验时对请求携带的API Key做同等哈希后再查询，可避免API Key泄露后被直接遍历集合窃取所有有效密钥。

2. 按用户UID查询所有API Key的效率 #

你担心的查询效率问题完全不存在，该结构下依然可以高效实现该需求：
你只需要在每个API Key文档中保留user_id字段，Firestore 默认会为所有单字段自动创建索引，你不需要额外做任何配置，即可直接执行条件查询。
参考集合结构：

查询指定用户所有API Key的示例代码（Web SDK）：

const getUserApiKeys = async (uid) => {
  const keySnapshot = await db
    .collection('api_keys')
    .where('user_id', '==', uid)
    .get();
  return keySnapshot.docs.map(doc => ({
    key: doc.id,
    ...doc.data()
  }));
}

Firestore的查询性能仅和返回的结果集大小相关，和集合总数据量无关，哪怕你存储了百万级别的密钥，只要对应用户名下只有N条密钥，该查询就只会产生N次读操作，完全满足你低频拉取的使用需求。 #

3. 额外注意事项 #

• 可新增is_enabled布尔字段实现密钥软禁用，校验时顺便判断字段状态即可，不需要直接删除文档。
• 务必配置Firestore安全规则，禁止客户端直接访问api_keys集合，所有读写操作都通过可信后端执行，避免数据泄露。
• 不要在该集合的文档中存储除密钥关联元数据之外的敏感用户信息，降低泄露风险。

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