必须用递归组件实现微博式转发嵌套，配合树形数据结构（含tree_id、parent_id、depth）、隔离文本解析、分离media字段及手写template渲染，才能避免错位、卡顿与状态混乱。
转发内容怎么嵌套展示才不乱套
微博式转发结构（原博 + 转发语 + 被转发博）不是简单堆叠，而是有明确层级和视觉隔离。uni-app 里硬套 v-for 或靠 margin 撑开，很快会遇到缩进错位、点击区域重叠、嵌套过深卡顿等问题。
- 必须用递归组件，不能靠 v-for 嵌套两层应付——第三层转发（A 转 B，B 转 C，C 转 D）时，扁平数据无法还原父子关系
- 每层转发节点需携带
isRetweet标志和retweetSource引用，否则点击「查看原文」会跳错位置 - 外层容器设
padding-left: 16px+border-left: 2px solid #eee模拟微博的引用线，但注意 iOS 小程序里border-left在 flex 子项中可能渲染异常，建议改用绝对定位伪元素模拟 - 转发语（即用户自己写的那句）要和被转发内容明显区隔：加灰色背景 + 左侧小图标 + 更小字号，别和原博样式混同
数据结构怎么组织才能支持无限转发嵌套
后端返回的数据如果只是 { content: '...', retweet: { content: '...' } } 这种两级结构，前端就只能硬编码两层。真正可扩展的结构必须带树形标识和深度控制。
- 要求后端返回字段含
tree_id（唯一树根 ID）、parent_id（上一层转发 ID）、depth（当前嵌套深度，建议限制 ≤ 5，防页面卡死） - 前端收数据后做一次扁平转树形处理，用
Map缓存所有节点，再按parent_id关系组装子数组，避免每次递归都遍历全量数据 -
depth不单是展示缩进依据，更是性能兜底开关：当depth > 4时，自动折叠为「… 还有 X 层转发」，点开才加载后续节点 - 别把转发内容整个塞进
content字段里拼 HTML——要拆成text、images、atUsers、topics四个字段，方便各自走对应渲染逻辑（比如topics要高亮可点击，images要走九宫格）
嵌套转发里的图片、话题、@人怎么保持独立解析
转发内容里可能同时存在图片、#话题#、@用户名，它们的解析逻辑互不干扰，但共用同一段原始文本。直接对整段 content 用正则全局替换，会导致嵌套层级错乱（比如外层话题把内层图片 URL 当作文本匹配了）。
- 每个转发节点的文本解析必须隔离执行：先取当前节点的
text字段，再单独跑/#(.*?)#/g和/@([^@\s]+)/g，别跨节点复用正则 lastIndex - 图片数组
images必须和文本分离传输，禁止把图片 URL 拼在content字符串里——否则富文本解析时会误把 URL 当作普通链接或触发 XSS 过滤 - 转发语中的 @人需要额外标记
isFromRetweet: true，和原博里的 @人区分，点击后跳转逻辑不同（原博 @ 跳用户主页，转发语 @ 跳评论输入框并预填） - 真机测试重点：iOS 微信小程序里，嵌套多层后
image组件的mode="aspectFill"可能因父容器宽高未稳定导致裁剪错位，务必给每层转发容器设固定min-height: 80px
为什么不用 rich-text 组件渲染转发内容
<rich-text> 看似省事，但它在转发嵌套场景下是隐形陷阱：无法绑定事件、不支持自定义标签、无法穿透控制子节点样式，且各端表现不一致。
-
<rich-text>渲染后 DOM 是只读的，你没法给其中某个#AI#加class="topic-tag"再委托事件——它直接输出纯 span，data- 属性全被过滤 - 嵌套转发时，你想让第 3 层的图片点击放大，但
<rich-text>里连image标签都不支持，只能退化成 base64 文本或空白 - H5 端
<rich-text>支持部分 CSS，小程序端只认白名单样式，比如padding-left在微信里无效，导致引用线对不齐 - 正确做法是手写 template：用
<view class="retweet-item">包裹每一层，内部用<text>+<view v-for="img in item.images"><image></image></view>分离控制，样式和事件完全自主
嵌套转发最易被忽略的是深度状态同步：用户在第 4 层点开一张图，滑动到第 2 层再点开另一张，两个图的预览索引、当前页码、关闭后是否回到原位置，这些状态必须按树节点隔离维护，而不是用一个全局 currentImageIndex 变量。否则真机快速切换时，图片预览会错乱甚至崩溃。
