大模型流式对话界面：从 SSE 接收到逐字渲染的前端架构

一、首字那一刻，用户在等什么

点完发送，光标在输入框里闪。第一秒过去，屏幕还空着。第二秒过去，仍然空着。第三秒，有人就关掉了。某头部智能助理产品去年复盘过一次，灰度期间首字延迟从 800ms 涨到 4 秒，次留直接掉 11 个百分点。老板盯着流失图复盘，研发才知道，体感比模型能力更影响留存。

这事我见过太多团队栽进去。大家都把精力放在 prompt 工程上，忘了首字延迟才是门面。流式输出正是为了解决这个等待焦虑。它把回答拆成 token 片段，边生成边展示。首字延迟从数秒降到几百毫秒，体感天差地别。

但工程上没这么简单。流式场景最大的难点是 Markdown 的上下文相关。一个未闭合的代码块、一个半截表格，都会让解析器崩或渲染出残品。某开源聊天组件曾出过事故：模型生成到一半输出一个反引号，前端整页 HTML 炸了 30 分钟。

更麻烦的是模型产物不可信。注入、敏感词、循环输出，这些都得在前端做兜底。我们曾经被一个用户提示诱导，模型输出了 </div><script>... 的恶意片段，没消毒直接渲染，半个团队周末在线救火。从此消毒是硬性流程，没得商量。

二、流式数据从网络到屏幕的链路

浏览器侧最常见的方案是 fetch + ReadableStream。服务端用 SSE 或分块传输，源源不断把字节推到前端。

字节流里有个坑：UTF-8 多字节字符可能被网络分片切断。直接按块 decode 会丢字。正确做法是用 TextDecoder 的 stream: true 模式，让它跨块拼接。我们项目上线后第一周，有用户反馈"中文突然变成乱码"，就是这个原因。补丁打上后问题消失。

数据流到前端后，还要解决单工方向的选择。SSE 基于 HTTP 长连接，天然适合"模型生成 → 客户端消费"的单向推送，断线后还能靠浏览器自动重连。WebSocket 是双向通道，对纯对话场景能力过剩，还得自己管心跳。多数团队会选 SSE，复杂度低一截。

文本攒到一定量，交给 Markdown 解析器。解析器输出抽象语法树，渲染层再映射成组件。每来一段就重渲染一次。综上，流式文本落到前端要过三关：字节流用 TextDecoder 的 stream 模式跨块拼接避免断字乱码；单向推送优先选 SSE，复杂度低且自带重连，双向需求才上 WebSocket；累积成 Markdown 后先做增量切分与未闭合结构保护，再交给渲染器。把这三关守住，流式消费才稳。

三、生产级流式对话渲染实现

下面这段代码是一个真实项目里抽出来的流式消费控制器。它把超时、取消、异常恢复都串成一条链路。

// 流式对话控制器：统一管理连接生命周期与渲染调度
class StreamChatController {
  private abortCtrl?: AbortController;

  // 发起一次流式对话，返回异步可迭代的增量文本
  async *streamChat(
    prompt: string,
    opts: { timeoutMs?: number; signal?: AbortSignal } = {}
  ): AsyncGenerator<string, void, unknown> {
    const { timeoutMs = 30_000 } = opts;
    this.abortCtrl = new AbortController();
    // 把外部中断信号转发到内部控制器，保证多处取消来源统一
    opts.signal?.addEventListener('abort', () => this.abortCtrl!.abort());

    const decoder = new TextDecoder('utf-8', { fatal: false });
    let buffer = ''; // 跨分片累积，避免中文被截断导致乱码

    try {
      const res = await fetch('/api/chat', {
        method: 'POST',
        headers: { 'Content-Type': 'application/json' },
        body: JSON.stringify({ prompt }),
        signal: this.abortCtrl.signal,
      });
      if (!res.ok || !res.body) throw new Error(`上游异常: ${res.status}`);

      const reader = res.body.getReader();
      const deadline = Date.now() + timeoutMs;
      while (true) {
        // 每次读取都检查超时，防止慢速流无限挂起占用连接
        if (Date.now() > deadline) throw new Error('流式响应超时');
        const { done, value } = await reader.read();
        if (done) break;
        buffer += decoder.decode(value, { stream: true });
        // 按行切分 SSE 帧，仅处理 data: 开头的有效负载
        const frames = buffer.split('\n');
        buffer = frames.pop() ?? '';
        for (const frame of frames) {
          if (!frame.startsWith('data:')) continue;
          const payload = frame.slice(5).trim();
          if (payload === '[DONE]') return;
          yield payload; // 逐片交还上层做增量渲染
        }
      }
    } catch (err) {
      if ((err as Error).name === 'AbortError') return; // 用户主动中断属正常路径
      throw err; // 真实网络故障向上抛出，由 UI 层提示重试
    }
  }

  stop() {
    this.abortCtrl?.abort(); // 释放底层 TCP 连接，避免推理资源空转
  }
}

三个不能省的点：超时阈值别超 30 秒，否则用户早就切到别的会话。AbortController 必须挂在组件卸载钩子里，连接不悬空。解码必须开 stream: true，跨片中文不乱。

渲染层别每个 token 都触发重渲染。稳妥做法是用 requestAnimationFrame 做批量合并：把短时间窗内的增量先攒进队列，下一帧统一 flush。把数百次微更新压缩成每秒约六十次绘制，主线程才有空跑别的逻辑。

四、流式渲染的边界与权衡

流式不是万能解。逐字渲染会持续触发布局与绘制，低端设备或超长回答仍可能卡顿。工程上要主动降级：当消息长度超阈值，切到整段到达后再渲染。某金融场景下大屏打开长文本，纯流式首屏耗时 6 秒，降级后压到 1.4 秒。

SSE 是单向通道。若业务需要把用户上下文回传做实时纠偏，要叠加独立的上行链路，复杂度上升。WebSocket 在双向交互频繁时反而更合适，但需自行实现心跳与重连，维护成本不低。

更要警惕的是半成品内容暴露。模型中途可能生成敏感或不完整片段，前端应在渲染同时做内容安全校验，发现风险立即中断并清空。医疗、金融这类强合规场景下，这是硬指标。

五、总结

流式对话界面的核心，是把网络协议、缓冲解码、渲染调度三层职责解耦。优先选 SSE 降低接入成本，用 TextDecoder 的流式模式解决中文跨片乱码，用 AbortController 统一中断来源。渲染侧借助 requestAnimationFrame 批量合并，并对超长内容做降级。落地时务必补齐超时、重试与安全校验。这条路在千万级对话下能跑通，回报是值得的。