小红书式评论折叠的核心在于动态判断是否收起，需结合真实行高计算、递归组件、tree_id分组、路径级展开状态管理及-webkit-box多行截断实现。
小红书式评论折叠展示，核心不是“怎么收起”，而是“怎么判断该不该收起”——它依赖真实行高计算、动态状态管理、以及对「回复链深度」的显式控制。直接用 v-if 或 max-height 过渡会漏掉关键交互点，比如点击某条回复后自动展开其父链、折叠后保留滚动位置、多层嵌套下输入框精准定位。
为什么不能只靠 v-for 嵌套两层
小红书评论常见结构是：主评 → 回复主评 → 回复该回复 → 再回复……这种链式盖楼在数据上是树形，但前端若硬写三层 v-for：
- 层级超过 3 层时，
item.replies[0].replies[0]这类路径极易报Cannot read property 'replies' of undefined - 分页加载新评论后，无法插入到正确父节点下，导致“回复 A”显示在“回复 C”下面
- 点击「回复王五」时，输入框弹出位置错位，因为靠数组下标
replyInputs[2]绑定，而列表动态增删后索引已失效 - H5 端可能渲染正常，但微信小程序里嵌套过深会触发
Maximum call stack size exceeded
必须用递归组件 + tree_id 分组
后端返回的数据结构要带明确的树形标识，否则前端无法构建可展开的父子关系：
-
tree_id表示整棵子树归属（如所有回复“张三”的评论都带tree_id: 101） -
comment_id表示直接回复对象（如“李四回张三”是comment_id: 101，“王五回李四”是comment_id: 102） - 前端拿到扁平数组后，先用
groupBy(tree_id)拆成根节点 + 子树映射表，再递归渲染 - 递归组件内必须加
v-if="depth ，否则用户发一条深度为 10 的回复，组件会无限递归直到白屏
折叠状态必须按树路径独立管理
不能用单个 isExpanded 控制整个列表，也不能用数组下标做 key —— 小红书每条评论的展开/折叠是独立行为，且需支持“展开某条后，其所有祖先自动展开”：
- 状态对象用路径做 key，例如
expandedMap['101-102-103'] = true，而不是expandedList[2] = true - 点击展开时，先向上遍历父路径（
101-102、101），全部设为true - 渲染时，用
v-if="expandedMap[getTreePath(item)]"控制内容是否显示，避免v-show在小程序里引发滚动错乱 - 初始默认只展开前 2 层，更深层用「查看更多回复」按钮触发，减少首屏渲染压力
行高截断必须用 -webkit-box，且配合 v-html 安全处理换行
小程序不认 line-clamp，而 text-overflow: ellipsis 对多行无效，唯一跨平台生效的是老式 WebKit 方案：
- 折叠态样式必须写死：
display: -webkit-box; -webkit-box-orient: vertical; -webkit-line-clamp: 2; - 文字含
\n时，不能直接{{ item.content }}，要用v-html并先replace(/\n/g, '<br>')
，但必须过滤 script 标签防 XSS - 更稳妥做法是改用
<rich-text></rich-text>组件，它原生支持\n转换，且自带 XSS 过滤，但注意它不支持自定义字体大小和颜色，需用nodes数组构造 - 「展开」按钮必须用
catch:tap，不是@tap.stop—— 小程序中stop在某些基础库版本里无效，catch才能真正阻断冒泡
最易被忽略的是：折叠状态和滚动位置强耦合。用户在长列表里点开第 15 条评论，展开后页面应自动滚动到该评论顶部，但 v-if 插入节点需要 $nextTick 后才能获取真实 offsetTop，而小程序里 uni.createSelectorQuery() 又有异步延迟 —— 这部分逻辑没兜底，就会出现“点了展开，但内容卡在视口外”。
