谁把大模型的标签切断了？记一次流式 HTML"川剧变脸"的破案现场

乍看之下，大模型最终拼出来的 HTML 结构似乎没问题——缺的是被切包拦腰截断的那半截标签。问题出在切包时机与累加字符串：残缺片段一旦写入 Content，就会跟着 v-html 一路渲染到终态。

我们顺着数据管道一路往下摸，终于在某次偶发抓包里，逮到了一个正在赶路的 SSE 数据切片（Chunk）：

// 某一个刚从网络蹦出来的 SSE Data Chunk
... </div>day-section"><strong>Day2 ...

这感觉就像是：后端大哥拿着一把西瓜刀，在大模型疯狂输出 Token 的时候冷酷地一刀切了下去，正好切在了 <div class="day-section"> 的大腿上。

前一半留在上一个数据包里了，前端手里现在只拿到了后半截：day-section"><strong>Day2。

前端拿到这半截断头文本，由于用了 Vue 的 v-html，二话不说就直接塞给了浏览器内核。

这时候，浏览器的 HTML 解析器（Parser）看着这串东西，估计也是一脸懵逼。但作为老牌工业级内核，它有一套傲娇的"错误恢复机制"（Error Recovery）：

当 message_end 到达时，流式推送确实结束了，但累加器里的 HTML 字符串仍含着 day-section"><strong>Day2 这类被切坏的片段。v-html 每次重渲染都会让 Parser 再跑一遍错误恢复，残缺片段就会作为文本节点稳稳钉在 Day 标题前面——不会自己消失，只能等人来修。

在揪出这个真凶之前，我们在群里和后端、算法的小伙伴反复拉扯，也踩了不少坑：

为了以后不在这类流式 Bug 上通宵，我们总结了一套"三步走"的速通秘籍：

后端：语义微型缓冲区

其实最完美的解法在后端。后端的流式推送网关可以加个"语义微型缓冲区"。当发现大模型吐出来的 Token 正处于 < ... > 标签内部时，先别急着往外发，憋一下，等遇到 > 标签闭合了，再把这一整段当作一个 Chunk 发给前端。源头不切断，前端不翻车。

前端：暖心的"防腐层"

如果后端兄弟业务排期太满，前端也得有自己作为纯爷们的担当。我们选择在数据喂给 v-html 之前的最后一步，加一层轻量的动态清洗函数：

/**
 * 暖心小棉袄：专门修复流式传输中被网络切断的 Day 标题
 */
export function repairBrokenTripDayTitle(rawText: string): string {
  if (!rawText) return '';

  // 严苛匹配：只有在 </div> 或 </p> 后面，紧跟被切断的类名和 Day 标题时才出手
  // 比如专门拦截：</div>day-section"><strong>Day3
  const brokenTagRegex = /(</div>|</p>)(day-section)?"><strong>Day(d+)/g;

  return rawText.replace(brokenTagRegex, (match, closeTag, _, dayNumber) => {
    // 悄悄把被切掉的 <div class="day-section"> 给它补上
    return `${closeTag}<div class="day-section"><strong>Day${dayNumber}`;
  });
}

折腾了大半天，这个 Bug 最终被我们优雅地按死在了沙滩上。

大模型时代的流式交互，看着很酷炫，但实际上是在完全无状态的网络流上，去强行构建有状态的 DOM 树。这中间的各种网络切包、长文本截断，无时无刻不在考验着前端管道的鲁棒性。

作为前端，我们不仅是把数据画在页面上的"切图仔"，在这种时候，我们更像是守在数据链路最后一公里的"清道夫"。多留个心眼，加一层防御性思考，下班的钟声就能敲得更响亮一些。