1. 背景

平时做的系统都是偏公司业务的系统，这次开发了一个用户评论的功能，同时开发了web版和H5版本的，因为没有做过这种C端的常用的功能，所以记录一下此次的开发，从参考友商设计到独立思考业务之间的区别再到实际开发，最后再优化细节，还是学到了很多东西。

2. 设计

不方便截图内部系统，所以开发的功能UI就可以参考小红书的帖子，最上面是内容，下面是评论区。

评论区每条评论包括用户头像，用户名、评论内容、评论时间、点赞按钮、回复按钮。同时针对该条评论如果有其他用户来评论了这条评论，那么在每一条评论下面有一个“展开xx条回复”的按钮。点击之后展开更多的回复，回复的评论的结构也和上面的评论结构一样。

3. 区别

首先小红书的定位是一款互动交流的平台，我们开发的是一个查看资讯的页面。两种不同的平台有如下区别：

1）定位：

        小红书侧重于用户侧分享，更注重用户体验和社区互动；

        资讯网主要用于用户获取新闻、行业动态、公司信息等，不太强调社区互动；

2）使用场景：

        小红书适合用户学习技能、寻找志同道合的人，总之，主打一个交友互动；

        资讯网主要适合获取最新消息，深入某个特定的领域资讯。比如我们这个资讯网就是主打获取公司内部某个方面的资讯。

总之大概区别大家可以想象是小红书和腾讯新闻的区别。

4. 相同

按道理来说像资讯网这种在评论的交互方面可能不需要支持太多功能，大多仅限于用户评论、分享资讯、点赞资讯就可以了。但是产品又不想把该平台打造成太严肃的资讯发布平台，想要多一代呢用户之间的互动，所以我们也像小红书一样支持用户之间的互相评论，支持点赞评论等。

5. 细节实现

如上图所示，评论分几种情况：

1）当评论没有回复时，就直接显示就可以；

2）当评论有一条回复时，要显示在该条评论之下；

3）当评论有多条回复时，要默认显示一条回复在最上面，小红书按照的排序是热度最高的评论放在最上面。按时间还是按热度就由产品自己来定了。

更多的一些开发细节，也是在开发过程中发现的。

首先说明一下我们定义了获取资讯详情接口、获取评论接口、点赞接口、发布评论接口四个接口。

1）资讯点赞时需不需要重新调获取资讯详情接口？

        — 不需要， 这会导致页面重新渲染，浪费性能，用户体验不好；直接用户点赞后，点赞接口成功执行成功后，前端自己手动将资讯点赞数量加一。

2）H5或者web都需要实现评论翻页。万一评论有几千条一次性加载出来肯定不现实，所以我们的做法时下拉到最底部后再调接口加载更多，当然针对评论的回复就是点击“展开xxx条回复”来加载，当加载的page数等于来totalPage后，那么就需要隐藏“展开xxx条回复”按钮。

3）基于第二条，我们又思考了一个问题，假如有多个用户在这个资讯评论了，如果我们下拉后加载评论接口，需不需要将其他用户的评论也加载出来。意思就是假如A和B在11:00同时进入了这个资讯，然后A评论了一条，那么B往下拉加载的时候需不需要将刚刚A的评论也加载出来，也就是我们能不能看见11:00之后的其他用户的评论？

        — 经过思考，我们系统的定位不是像qq微信这种实时的聊天工具，所以是不需要的，经过小红书验证，小红书也是不会加载新的评论的。所以解决方法就是在接口加一个参数，加一个进入页面的时间参数，这样接口每次都只返回在这个时间点之前的评论，就不会导致上面的问题。

4）评论被点赞后需不需要重新调获取资讯评论接口？

        — 不需要，这就更加没必要了，想象下如果此时我们已经下拉查看了几百条几千条，只为了一个点赞就重新加载几百条，性能肯定不好，而且在调接口的逻辑方面不好控制。

5）同样，评论之后需不需要重新调获取评论接口？

        — 不需要，我们的做法也是在接口返回成功后，需要接口将这条评论的信息都返回给我们，比如时间啊，评论人姓名啊之类的，然后前端手动将这条评论推到评论列表。如果是评论的回复的话，那么默认推到评论的回复的第一条，如果是评论的回复的回复，就是A下面有个评论B，C又对B进行回复，那么要将这条回复手动插入到B这条评论后面第一条。在重新进入页面后，这些所有评论就按照时间或者热度排序就行。

6. 总结

总的来说，这次开发逻辑和平时的开发不太一样，平时的开发在更新列表后是需要实时调接口刷新的，而这次的是手动插入列表里面，其实呢代码实现难度不难，就是要理清评论的交互逻辑，这对第一次开发这类需要的我还是需要好好思考的。以后再遇到这类评论的功能就手拿把掐了，哈哈。