应采用树形结构存储转发内容，如含repost_of字段的嵌套对象，前端用递归组件渲染并支持折叠展开；配合视觉锚点、层级衰减样式和精准路径跳转，确保多层转发清晰可交互。
转发内容怎么结构化存储才不乱套
微博式转发本质是「原文 + 转发语 + 可能再转发」的嵌套链，不是简单拼字符串。如果后端只返回扁平字段（比如 content 和 repost_content），前端渲染时会丢失层级关系、无法折叠/展开、点击「查看原文」定位错乱。
必须要求后端提供带树形标识的结构，例如：
{
"id": 201,
"content": "刚看到这个新闻...",
"repost_of": {
"id": 101,
"content": "突发！XX事件发生",
"user": { "name": "官方号" },
"repost_of": null // 表示这是原始帖
}
}
前端拿到后，用递归组件渲染，每层判断 repost_of 是否存在；不存在则停，存在则继续递归。避免用 v-for 嵌套三层硬写——深度一超就卡死，且无法响应「收起全部转发」这类交互。
嵌套转发的样式怎么避免视觉爆炸
连续三四层转发堆在一起，用户根本分不清哪段是谁说的。关键不是加边框或缩进，而是用「视觉锚点 + 层级衰减」：
- 第一层（当前帖）：正常字号、深色文字
- 第二层（直接转发源）：左 border: 2px solid #007AFF，padding-left: 12px，字号 95%
- 第三层及以后：border-color 改为 #999，字号降到 90%，加
opacity: 0.85 - 每层顶部加小图标：
→或?，比纯文字「转发自」更轻量
别给每层都加 background 或阴影——小程序里渲染压力大，真机容易掉帧。
点击「查看原文」怎么精准跳转不穿帮
用户点最内层转发的「查看原文」，不能只跳到第一层原始帖 ID，得还原完整路径：从当前节点一路向上取 repost_of.id，拼成数组 [201, 101]，再传给详情页。
否则会出现两种穿帮：
- 跳转后页面显示「转发自 101」，但用户实际是从 201 进来的，上下文断层
- 详情页没做路径回溯，点「返回」直接回到上一页，而不是回到转发链中的上一级
建议在详情页 onLoad 里解析 path 参数，用 uni.navigateBack({ delta: N }) 控制返回深度，N = 路径数组长度 - 1。
微信小程序里 rich-text 怎么兼容转发嵌套
<rich-text></rich-text> 不支持嵌套 HTML 或事件绑定，所以不能把整个转发结构塞进去渲染。必须拆解：
- 外层用
<view></view>手动拼结构，控制层级和样式 - 每层的正文内容（含 @、#、链接）单独走富文本解析逻辑，生成
nodes数组传给<rich-text></rich-text> - 「查看原文」按钮必须放在
<view></view>层，不能塞进<rich-text></rich-text>的nodes里——它不认bindtap
特别注意：nodes 数组里不能写 data-* 属性，得用 attrs: { 'data-id': '101' } 格式，bindtap 回调里通过 e.detail.tapIndex 查表反推原始数据。
嵌套转发最难的不是渲染，是数据边界——每一层的发布时间、点赞数、评论数是否独立？如果后端把所有统计都挂在最外层，那中间层点「点赞」就根本不知道该累加谁的计数。这个逻辑必须提前对齐，别等 UI 做完了才发现数据漏了。
