Firebase/Firestore中item内存储用户数据的实现方案选择咨询

核心结论 #

你倾向的第二种冗余存储方案是Firestore场景下的标准最优实践，绝大多数情况下优先选这个方案。

两种方案的优劣势对比 #

• 方案1（仅存UID，查询时关联）
  仅适合单页内容量不超过10条、对用户信息实时性要求100%一致的极小众场景。优势是不需要处理数据同步逻辑，用户改信息不需要额外操作；但劣势非常突出：

  • 每次加载内容都要额外发起批量用户查询，读请求消耗是方案2的2倍以上，长期下来配额成本更高
  • 前端需要做UID和用户数据的匹配逻辑，增加代码复杂度
  • 网络请求多了一轮，页面加载延迟明显升高，内容量越大体验越差

• 方案2（冗余存储用户展示字段，云函数同步更新）
  完全契合NoSQL数据库「读多写少场景优先优化读性能」的设计思路，适合90%以上的内容类场景：

  • 读性能拉满，单次查询就能拿到所有渲染需要的字段，没有额外请求，加载速度快，配额消耗更低
  • 用户修改个人信息的频率极低，就算单个用户有数千条关联内容，批量更新的写入成本也远低于日常读请求的成本差
  • 前端逻辑简单，拿到数据直接渲染即可，不需要做额外的关联匹配

优化建议 #

如果担心用户关联内容过多时云函数批量更新超时，可以做两个小调整：

1. 给PHOTOS、VIDEOS集合的uid字段加单字段索引，云函数更新时分页拉取关联内容，分批次更新，避免单次请求超时
2. 前端加一层轻量的用户信息缓存，已经加载过的用户信息存在本地内存/Storage里，渲染时如果遇到缓存的UID直接用缓存数据，作为云函数同步延迟的兜底，保证用户看到的信息是最新的

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