列表项状态处理最佳实践：前端计算还是API后端返回？

你当前采用的前端本地比对方案，实际落地后会出现不少难排查的问题：

• 数据一致性没有保障：如果用户换设备登录、或者在其他端完成了收藏/评论操作，当前端本地会话存储的已持有、已评论列表没有同步到最新状态，热门页的按钮文案就会直接显示错误。要是为了规避这个问题，每次进入热门页都全量拉取用户所有历史收藏、评论记录，产生的流量开销远大于后端直接在20条图书数据里附带两个布尔字段的成本。
• 无端增加前端冗余负担：前端拉到图书列表后，还要遍历匹配两份本地数据集做状态转换，平白增加列表渲染前的处理成本；而且前端存储的用户行为数据本身不具备权威性，后续如果做和状态绑定的交互（比如点击已评论按钮跳转至用户自己的评论详情页），前端计算出的状态一旦失准，会直接导致交互报错。
• 后端实现这套逻辑的成本极低，完全不会造成性能压力：基于MongoDB实现时注意不要写循环查询单本书状态的N+1逻辑即可，直接走聚合管道就能一步完成计算：
  1. 先按预设的热度规则排序，截取Top20的图书记录
  2. 用$lookup分别关联当前请求携带的用户ID在收藏表、评论表中的匹配记录
  3. 最后用$project把关联结果转换为isOwned、isReviewed两个布尔字段，和原有的公共书评信息一起返回即可
     整套查询建好对应索引的话基本是毫秒级响应，比前端拉全量用户数据再做比对的效率高得多。

唯一适合把这层逻辑放在前端实现的场景，是你需要做热门页的完全离线可用，必须依赖本地缓存数据完成渲染，除此之外都应该优先把和用户身份强相关的状态计算放到后端，前端拿到数据后直接映射渲染即可，链路更短，逻辑更清晰，出问题的概率也更低。

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