在线社区之中，表面看似简单的评论功能，其背后实则存在着各异的设计逻辑，而这各异的设计逻辑，直接对用户的互动体验产生作用引发响。
不让回复的评论结构
在这种设计情形之下，用户仅仅能够发布单独的评论，然而却没办法直接去回复其他人。它所具备的最为突出的优点便是结构简易，达成成本低廉，能够迅速上线。针对于某些应用场景而言，像是应用商店的用户打分这儿（就好比早期的PP助手），又或者是豆瓣电影的短评区域，评论的核心效用是用来表达态度而非进行深入探讨，这样的结构便已然足够了 。
可是，它存在着明显的缺陷，那就是：彻底切断了用户之间能够直接对话的可能性。评论区会演变成一系列观点的平行排列展示，缺少相互交锋以及共鸣。这对于那些把评论当作附属功能的产品来说是适用的，这类产品的首要目的是呈现用户反馈，而不是营造培育社区氛围。
盖楼式评论结构
会以一种不断增长的新评论样式，把整个对话链条完整呈现出来的盖楼式评论，每一条新回复都会造就包含所有历史内容的新“楼层”，这样的设计能让对话的前因后果清晰明了，在视觉方面使得评论区显得极为活跃，易于营造出热烈的讨论气氛。
只是，这种方式存在着弊端，那便是会产生大量内容重复，同一段对话会在不同楼层当中反复出现，进而造成信息冗余，常见的解决方案是折叠中间楼层，仅仅显示最新回复以及对话起点，用户点击之后能够展开查看完整历史，网易新闻客户端等应用采用了这种折叠策略来平衡连贯性与简洁性 。
主题式评论结构
在这样的结构当中，每一条主评论，以及其下面的所有回复，它们共同组合成一个独立的对话“主题”。回复能够进行嵌套，继而形成树状结构，不过所有的讨论都被限定在这个主题的范围之内，不会对其他主评论造成干扰。这跟传统网络论坛或者贴吧的楼层模式相类似。
微博，采用了这种形式，简书，同样采用了这种形式，京东商品评价的回复区，也采用了这种形式。它将围绕特定观点的讨论很好地组织起来，进而致使话题变得集中。有一个设计技巧较为实用，那就是把同一主题下的回复按照时间顺序正序排列，而不是倒序排列，如此能够确保两人连续对话的阅读具备连贯性，防止被其他用户的插入回复打断。
截取式评论结构
可以将截取式视作主题式的一种经过优化的变体，它不是完整地展现整个主题树，而是在用户点击查看某条具体回复之际，仅仅动态加载并显示与该回复直接有关的局部对话链条，这如同从一棵大树之上截取了一根树枝来进行观察。
比如说，于虎扑体育客户端处，或者网易云音乐的乐评区域里，当你针对某一条特定的评论去进行回复时，界面会把你跟对方之间的一来一往对话清晰显示出来，而非搅和着全部不相关的回复。如此的方式，阅读体验更为集中、更加畅顺，在回复链较长那样有深度的讨论方面尤为妥善。豆瓣影评的评论区域也运用了相像的逻辑 。
评论结构的组合与选择
实际的产品当中，评论的结构并不是一直保持不变的，而是常常依循着具体的场景去进行相应的组合。比较常见的做法是，在其外层运用主题式的结构，以此来区分不一样的主话题，然而在每一个主题的内部呢，对于回复的展示采用的是截取式的逻辑。就好比说，猫眼电影以及淘票票的评论区，融合了这两种方式。
这种结合兼顾了话题的宏观架构以及微观交流的明晰度，产品经理要依据业务特性来进行抉择，新闻客户端着重时效与热度，或许会偏向盖楼式，知识社区看重讨论质量，也许会选用主题式或者截取式 ，豆瓣在不同板块运用不同结构，正是基于这种场景化的思索 。
评论设计的核心考量
评论功能的设计，并非如同技术实现那般简之又简，其本质实则在于平衡多种需求，具体涵盖开发效率、用户体验、社区氛围以及内容管理成本。简单的无回复结构较能节省资源，然而却会牺牲互动；复杂的嵌套结构有助于促进交流，可却有可能增加阅读以及理解负担 。
对于产品决策者而言，需要向自己提出这样的问题：在评论区里，其核心价值究竟是什么呢，是去收集相关的反馈意见，还是为提高用户方面的粘性，又或者是用以激发对应形式的内容创作呢，最终的答案将会直接对进行结构的选择起到决定性作用。伴随社区不断地发展，评论结构同样也有可能会需求进行一些迭代工作，具体来说就是，最开始是从简单的结构着手进行，等到社区发展成熟之后，再去引入更为复杂的回复功能。
什么样的评论结构的产品是你最为经常去加以使用的呢？并且你觉得哪种结构是最能够推动那具备价值的讨论得以开展的呢？欢迎于评论区之中把你的看法分享出来，要是感觉受到了启发，同样也请进行点赞给予支持。
