Firestore中高效存储与查询帖子点赞/踩赞的最佳实践

原方案的核心问题 #

每个帖子需要3次独立查询：获取帖子内容、检查用户是否在liked_by集合、检查是否在disliked_by集合，请求冗余且效率偏低，尤其在用户点赞当前展示帖子概率不高的场景下，大部分检查查询都是无意义的。

优化方案 #

1. 合并状态检查为批量查询

利用Firestore的批量读取能力，对每个帖子，在获取帖子内容后，用Promise.all同时发起liked_by/{userId}和disliked_by/{userId}的存在性查询，将原本串行的2次检查合并为一次并行请求。这样单帖的总查询次数从3次降到2次，并行请求还能缩短整体响应时间。

2. 在用户文档中用Map存储点赞/踩赞状态

放弃用户子集合的方案，改为在用户文档中新增两个Map类型字段：likedPosts和dislikedPosts，以postId为键，值设为true或点赞时间戳。

• 查询逻辑：先一次获取当前用户的文档，拿到两个Map后，在客户端直接判断要展示的每个帖子ID是否存在于Map中。
• 优势：查询总量变为1（用户文档）+N（N个帖子内容），比如展示30个帖子时仅需31次查询，远低于原方案的90次；Map的存在性判断是O(1)操作，客户端处理效率高；单用户点赞数即使到几千，文档体积也远低于1MB的限制，扩展性足够。

3. 客户端缓存点赞状态

将用户的likedPosts和dislikedPosts缓存到本地存储（如LocalStorage、AsyncStorage），APP启动时同步一次最新状态即可。展示帖子时直接用缓存判断，无需每次请求Firestore；仅在用户执行点赞/踩赞操作时，同步更新缓存和Firestore，进一步减少查询次数。

对原有备选方案的优化补充 #

• 针对数组存储的问题：用Map替代数组，既解决了数组体积随点赞数增长过快的问题，又将客户端的存在性判断从O(n)优化为O(1)。
• 针对用户子集合的问题：用文档内的Map替代子集合，避免了获取全部子集合文档的冗余操作，一次查询即可拿到所有点赞状态。

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