评论区提供了用户与用户、读者与创作者及用户与平台之间的互动交流，本身也是内容衍生品。近期工作涉及，就简单记一下看到的。
概述：一. 评论区结构；二. 评论上传图片；三. 一个小疏漏。
一. 评论区结构
常见的评论区结构，分为3类：
No.1 主题式设计（树形分支结构）
每条主评论（一级评论）都作为一个“主题”，而这条主评论的回复（二级评论）都被当成“主题”的子集。
举个栗子就是微博：
优点：
1.内容更聚焦，前后对话清晰；
2.便于筛选优质评论（利于运营）；
3.对于一级评论而言，密度更大，展示更多。
/
缺点：
1.回复的二级评论隐藏较深，要再次展开查看新内容（为弥补这个缺点 大多应用都露出部分回复，提高可见性）；
2.易被蹭热门一级评论“前排灌水”。
题外话：对比微博和云音乐，都是主题式设计，但对于回复评论处理，却有不同。
微博 是仅@原评论用户：「用户A 回复 用户B：回复内容CCC」。相比较会更节省空间，牺牲的是他人视角的上下文阅读（当两人的回复中间插入了别人的回复时，阅读不连贯）；
云音乐 引用原评论：除了展示 用户A 的回复内容，还会引用 用户B 的原评论一起展示出来。阅读上稍好，但容易造成平铺式的问题，原评论信息不断重复。
No.2 平铺式设计
所有评论/回复都是一级页面，无二级页面，每一条都作为新的评论展示出来，层级并行。
举个栗子就是： 豆瓣小组
优点：
1.对每一条回复来说，曝光相对平均，对优质二级评论有利；
2.适用于对于评论量不大项目 / 或运营初期，利于渲染热评氛围。
/
缺点：
1.产生讨论时，阅读连贯性差，米有上下文交代；
2.回复的内容属于二次互动行为，易产生与原文章无关或重复冗余评论。
No.3 盖楼式设计
指每次对原评论的回复，都把原评论内容露出，并带上自己的评论，以“圈层”样式呈现，久而久之就形成无限嵌套的方框样式，叫做“盖楼”。
不常见，不多说。
二. 评论上传图片
1. 传图
a. 传图到服务器一般来说有两种选择：
一是先选择本地上传，点击发布后再统一传到服务器（节约编辑中的流程时间、减少选错图重复上传浪费流量及便于离线后断点重新发布，但图片上传状态和错误信息不好实时掌握）；二是选图后就直接上传，等传输全完成后才发布。
b. 关于图片审核和不通过图片
先发后审。
不通过的图则不再展示（不占位，当出现大量违规图时，占位默认图对他人来说本身也算是垃圾信息。）
展示大家会不会心知肚明原因然后一大堆求原图呢。
2. 图片展示
针对单图（只有一张图）多图（不少于2张）两种情况，自我提出了三种图片显示比例方案：
a. 统一固定 1:1 宽高比
逻辑简单粗暴，多图时为了节省空间，展示样式没有争议；
但单图的问题就很大，基于原图裁剪过多，预览图识别性差，几乎每张图都需要再次点击看原图才能知道内容。
b. 依据原图比例套模板
按原图比例，定了3种模板：方图、宽图、长图，对应着嵌套。
这样做法没什么大问题，长图会被裁剪也是合理的，但非长图时就和我的初衷有点出入，没有很好解决原图被裁减的问题。基于此，又有了第三种。
c. 原图等比缩放
将单图划分为两种形式：长图和单图。
长图判断：高 / 宽 > 3
-> true 则走长图裁剪逻辑
-> else 则走等比缩放
等比缩放能让非长图的单图不会被裁剪，更还原图片信息；而长图时则固定宽高，顶部裁剪，保留图片头部信息作为预览。
题外话：多图时，因为样式原因，经常看到的是一种「逼死强迫症」的非3倍数，这时往往用户喜欢发所谓的「占位图」来凑齐。
腾讯视频 doki 区则对这种情况做了处理（5图/7图/8图时），
比如以下情敌们发的图：
三. 一个小疏漏
方案3忘记定最小图片范围了，如果发了个比 emoji 还要小的图片，预览图可能就看不清了（不过这种情景也很少吧）。
做法是定个最小值，执行放大之术。
如果你觉得我哪里想的不好，请不吝拉我一把，简信评论都可。
参考文章：
非常感谢下列文章，文中部分观点的来源
10个关键点，告诉你如何设计产品评论模块
关于评论区的产品设计
评论结构设计及防刷
