必须用递归组件+树形数据结构，因v-for嵌套两层无法支持无限盖楼、易卡顿、父子关系丢失、回复定位错位；需tree_id分组、depth限深、replyInputMap绑定、key含深度。
直接用 v-for 嵌套两层就能撑起朋友圈式评论，但真要支持「回复谁」「展开收起」「无限盖楼」，必须用递归组件 + 合理的数据结构，否则很快会卡死或渲染错乱。
为什么不能只靠 v-for 嵌套两层
朋友圈评论不是固定两级：A 评论 → B 回复 A → C 回复 B → D 回复 C……这种链式回复在真实场景中很常见。硬写三层 v-for 不仅难维护，还会导致：
- 层级深度无法控制，用户点开一个深嵌套评论后，页面可能卡顿甚至白屏
- 数据扁平化时丢失父子关系，比如分页加载新评论后，无法准确插入到对应父节点下
- 点击「回复某人」时，输入框定位和上下文绑定容易出错，
replyInputs[index]这种靠数组下标的方式在动态增删后极易错位
commentList 数据结构必须带 tree_id 和 comment_id
后端返回的数据如果只是简单嵌套（如每个主评论带 replies: []），前端就只能支持固定两层。真正可扩展的结构需要包含树形标识：
[
{
"id": 101,
"content": "这图太棒了",
"user": {"id": 1, "name": "张三"},
"tree_id": null, // 是根评论
"comment_id": null
},
{
"id": 102,
"content": "哈哈同感",
"user": {"id": 2, "name": "李四"},
"tree_id": 101, // 属于根评论 101 的整棵子树
"comment_id": 101 // 直接回复 101
},
{
"id": 103,
"content": "楼上是张三小号？",
"user": {"id": 3, "name": "王五"},
"tree_id": 101, // 同属 101 的子树
"comment_id": 102 // 直接回复 102
}
]前端拿到这个结构后，先按 tree_id 分组，再对每组做递归渲染——这样既能支持任意深度，又避免重复请求。
递归组件必须加 v-if 控制渲染深度
Uniapp 的递归组件本身不带深度限制，不加防护会触发无限渲染或内存溢出。正确写法是在子组件里显式判断：
<template>
<view v-for="item in list" :key="item.id">
<!-- 当前层级 -->
<comment-item :data="item" />
<!-- 下一级：只渲染 depth < 3 的子树 -->
<comment-list
v-if="depth < 3"
:list="item.children"
:depth="depth + 1"
/>
</view>
</template>其中 depth 从父级传入，默认为 0；超过阈值就停止递归，改用「展开更多」按钮触发展开逻辑。
「回复某人」的输入框必须绑定到具体 comment.id 而非数组索引
用 replyInputs[index] 这类基于下标的绑定，在插入/删除评论后会完全错位。应该用对象映射：
- 定义
data() { return { replyInputMap: {} } } - 输入框绑定：
v-model="replyInputMap[item.id] || ''" - 提交时读取
this.replyInputMap[item.id]，清空也只清这个 key
这样无论列表怎么重排、增删，每个评论的输入状态都独立且稳定。另外，点击「回复」按钮时，建议把焦点自动落到对应输入框上（uni.focusElement 在 App 端可用，H5 需 fallback 到 el.focus()）。
最易被忽略的是：递归组件的 key 必须包含深度信息，比如 :key="item.id + '-' + depth"，否则 Vue 在 diff 时可能复用错误的子组件实例，导致展开/收起状态混乱或事件绑定错乱。
