Firebase用户数据存储：存于认证档案还是数据库？

好问题！这是Firebase开发中很常见的设计决策，我来帮你理清楚：

一、用户额外信息（年龄、体重等）的存储位置 #

绝对不建议存在Firebase Auth的用户对象里，原因很简单：

• Firebase Auth的核心定位是身份认证系统，不是业务数据存储工具。它只提供了基础的身份字段（比如uid、phoneNumber、邮箱、displayName等），没有预留自定义业务字段的空间（虽然可以用自定义Claims，但Claims有1000字节的大小限制，且是公开可通过ID Token获取的，不适合存储年龄、体重这类业务数据）。
• 扩展性差，后续如果要增加更多用户属性，Auth完全满足不了；查询、筛选这些数据也非常不方便。

正确的做法是：在Firebase Firestore（或Realtime Database）中创建一个users集合，每个用户对应一个文档，用FirebaseAuth.instance.currentUser!.uid作为文档ID（或者把uid存在文档的字段里），然后把年龄、体重、偏好等业务信息存在这个文档中。

二、用户数据关联：选uid还是phoneNumber？ #

这个要根据你的业务需求来权衡，但我会先给你两种方案的优劣：

优先推荐：关联uid #

• 唯一性与安全性：每个用户的uid是Firebase Auth自动生成的唯一标识，和用户的Auth账号强绑定。你可以通过Firebase安全规则轻松实现权限控制，比如只允许用户修改自己的文档：

  match /users/{userId} {
    allow read, write: if request.auth != null && request.auth.uid == userId;
  }
  

  这种方式的安全性和便捷性是最高的。
• 无冲突风险：即使用户后续修改手机号/邮箱，uid不会变，数据关联不会断裂。

特殊场景下考虑：关联phoneNumber #

你提到的“删除用户后重新注册，uid变但phoneNumber不变，想保留旧数据”是一个合理的业务场景，这时候可以考虑用phoneNumber作为关联键，但要注意几个问题：

• 唯一性校验：确保你的业务中phoneNumber是唯一的（Firebase Auth本身会验证手机号唯一性，但如果用户换号，你需要同步更新数据库中的关联字段）。
• 安全性妥协：用phoneNumber做关联的话，安全规则的编写会更复杂，需要验证当前用户的phoneNumber和文档中的phoneNumber匹配，而不是直接用uid。
• 折中方案：可以在users文档中同时存储uid和phoneNumber两个字段。日常操作（比如用户读取/修改自己的数据）用uid做权限控制；当用户删除账号后重新注册时，通过phoneNumber查询旧文档，将历史数据迁移到新uid对应的文档中，或者建立新旧文档的关联关系。

总结一下：日常开发优先用uid关联，特殊业务场景下可以结合phoneNumber做数据迁移或关联，但不要放弃uid的权限控制优势。

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