Firebase Firestore用户数据存储最佳实践及Android社交应用用户名展示方案选型咨询

刚好之前做过类似的社交应用场景，咱们来拆解下你的两个方案，再聊聊更接地气的解决思路：

先说说你提出的两个方案的利弊 #

方案一：用Cloud Functions的getUserNameById() #

• 好处是用户名永远是最新的，毕竟每次都是从user_collection实时拉取，不会出现旧名称的问题。
• 但痛点也很明显：滚动Feed时频繁调用函数，一来会拉高你的Cloud Functions费用，二来网络请求多了肯定会导致Feed加载卡顿，用户体验会打折扣。要是Feed里有同一个用户的多条帖子，重复调用更是纯纯的资源浪费。

方案二：在post_doc里存用户名 #

• 优点是读取效率极高，刷Feed的时候直接从帖子数据里拿用户名，不需要额外请求，流畅度拉满。
• 但用户改了名字之后，旧帖子还显示旧名字，这个数据不一致的问题会让用户觉得很奇怪，体验上有点别扭。

更优的折中方案：结合两者+小调整 #

其实可以把两个方案的优势捏到一起，同时解决各自的缺点：

1. 冗余用户名+Cloud Functions同步更新 #

• 用户发帖子的时候，把当前的用户名和userId一起存入post_doc，保证刷Feed时能直接拿到名字，不卡壳。
• 给user_collection加个Cloud Functions触发器：当用户修改自己的名称时，自动遍历这个用户所有的帖子，把帖子里的用户名批量更新成新的。
  • 要是用户发的帖子特别多，别一次性全更，分批次用批量写入处理，避免函数超时。

2. 调整安全规则（最推荐的思路） #

其实社交应用里，用户名本来就是公开信息对吧？你之前的安全规则可能太严格了——可以给user_collection加一条规则，允许所有人读取用户的公开字段（比如用户名），只限制修改权限：

match /user_collection/{userId} {
  allow read: if true; // 所有人都能读公开信息
  allow write: if request.auth.uid == userId; // 只有本人能改自己的数据
}

这样客户端直接通过userId就能从user_collection拉取用户名，再配合本地缓存（比如用SharedPreferences或者Room存userId-用户名的映射），第一次取了之后后面直接用缓存，既保证了名字是最新的，又不会有频繁请求的问题，完美解决你的痛点。

总结下优先级 #

如果用户名是公开的，优先调整安全规则+本地缓存，这是最省心成本最低的方案。要是必须严格限制用户数据读取权限（比如只有本人能看自己的所有数据），那就选「冗余用户名+Cloud Functions同步更新」，再配合客户端缓存减少函数调用次数。

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