你可曾察觉到，每日于手机之上轻点“发送评论”之际，那处于背后的不大的输入框之旁，隐匿着产品经理满心的苦衷？自为斟酌中午吃啥观摩团购评分作起，直至于这篇文章下方抒发你对评论所秉持的见解之时，我们差不多每日皆与评论有所关联。然而鲜少有人思量过，去设计评论版块的架构，尤其是当“回复”功能现身而后，那种衍生不息的嵌套逻辑，究竟应当怎样去处置，方可既使用户畅快交流，又不让程序员焦虑失措。

最简单但最孤独的选择

那种不允许用户相互进行回复的评论结构，在所有的方案当中是最为省事的。它具备的优点十分直接，开发所需的成本比较低，上线的速度比较快，数据库承受的压力比较小。然而缺点同样是非常明显的，整个评论区域就仿佛是一堵墙，每一个人张贴完属于自己的纸条之后就离开了，彼此之间不存在任何的互动。这样的设计适用于两种场景，一种是你根本就不看重评论功能，只要有个地方能够让用户说上一句话就可以了；另一种情况恰恰相反，你极其重视评论的质量，期望用户经过深入思考之后再去发表观点，就像豆瓣的短评区域，又或者是那些专门设置有问答板块的应用。PP助手、豌豆荚用的就是这种结构。

热闹但容易失控的盖楼

盖楼式评论，简单来讲，就是每一条回复都会带着之前所有的“家当”一同出现，这种设计最大的益处是视觉效果极具冲击力，一条热门评论下方能够拉起成百上千层楼，远远看去社区氛围十分火爆，然而它的代价也与楼层数呈现正比例关系，首先面临的就是内容重复堆叠的问题，为了解决这一问题，网易新闻客户端采用了一种折中的办法：折叠中间楼层，不过操作起来存在很让人纠结的地方，比如你回复的是第5条，那么前4条是不是要保留呢？并且，为了突出楼层的那种感觉，越是早一些的回复，缩进的程度就越大，等到楼层数突破了一百的时候，前面那些内容已经缩至屏幕的边缘位置了，简直根本没有办法去看了。

整洁与深度的平衡点

那被称作贴吧式评论的主题式评论，其核心逻辑乃是将每一条原始评论视作一个独立主题，所有针对该评论的回复，涵盖回复的回复，皆收纳于这个主题范围之内，需用户点击方可展开查看，这种结构使得评论区主界面看上去颇为清爽，解决了盖楼式那种页面冗长的问题，优酷客户端采用了此种方式，他们会展示部分回复内容用作引导。京东、微博、简书所采用的同样是这般结构，然而此处存在一个设计方面的细节需要予以留意，要是依照时间倒着的顺序去排列回复，而两条前后连贯的对话当中插进了其他人的回复，那么读起来就会出现思维中断不连贯的状况。

解决冗余的截取式

先说截取式评论，它针对盖楼式具有的两大痛点实施精准优化，它并非把整条对话链都搬出来，而是仅保留最新那个回复，且在其中截取引用部分内容，如此一来，界面不会堆积诸多重复信息，也无需担忧楼盖过高引发的缩进问题，然而其缺点是牺牲阅读连贯性，只能看到最后一句对话，看不到前因后果，网易云音乐采用这种结构，但其显示方式是回复在上、被其回复在下，不太契合日常阅读习惯，况且每条评论都加上艾特，显得有点累赘。

不同场景下的混合搭配

在实际的应用当中，极少存在产品仅仅顽强地执着于一种结构。猫眼电影跟淘票票所采取的方式极为明智，从外观上去看呈现的是主题式评论，以此可维持界面的整齐干净；当点击进入之后，其内部的回复流运用的却是截取式，借此避免了信息的过度泛滥。而豆瓣算得上是一个针对评论结构展开研究的优质范例，它的短评区域、影评区域以及小组讨论区域，依据不同的业务要求采用了全然不一样的结构，虽说这增加了开发方面的工作量，然而却展现出了产品经理依据场景灵活进行选择的能力。虎扑体育所使用的截取式在阅读的顺畅程度方面比网易云音乐做得更具合理性。

为什么一开始就要选对

并非所有这些结构，都存在绝对的好与坏之分，仅仅存在适合与否的情况。要是你的目标在于提升评论区活跃度，想要促使用户发生争吵，盖楼式的确能够营造出火爆的假象；要是你期望兼顾活跃与整洁，主题式乃是稳妥的选择；要是你担忧数据量增大之后难以改动，那么截取式或许是更为轻量的方案。最害怕的是，一开始贪图省事选择了个简易的，等到用户数量攀升上来，评论区的数据堆积如小山，才发觉其中的弊端，那个时候再想要更换结构对产品、开发、测试而言都是一场灾祸，数据库迁移、历史数据兼容无论哪一件都足够让人折腾。

看过这几种评论区的设计门道之后，你可曾思考过，自己每日所使用的那些App，它们的评论结构归属于哪一种类别？再者，你认为哪种评论方式会最使你萌生出想要发言的欲望呢？对此，欢迎于评论区交流分享你的观察所得。