企业官网建设流程全解析

大模型流式对话界面的工程实践：SSE 推送与增量渲染架构

一、首字延迟：3 秒白屏为什么能把人逼走

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

如果前端采用传统的请求—等待—整段返回模式，用户往往要面对三到八秒的空白界面。这种空白会直接触发焦虑感，并提高页面跳出率。

流式输出把整段响应切成令牌碎片，后端一边生成，前端一边渲染。它把不可见的等待时间，转化成了可见的生成过程。这是一种体验上的本质改变。

但流式并不只是把数据接住再显示那么简单。它涉及网络协议选型、文本增量解析、Markdown 段落的渐进渲染，以及断线后的状态恢复。任何一环处理粗糙，都会让"流畅"变成"闪烁"。

二、SSE 协议：为什么选它不选 WebSocket

浏览器与服务端之间，主流的流式通道有三种：轮询、WebSocket 和 SSE。轮询延迟高、副作用大，不适合对话场景。WebSocket 是全双工通道，能力过剩且需要独立连接管理。

SSE 基于 HTTP 长连接，天然对齐大模型"服务端单向推送"的语义。它使用text/event-stream媒体类型，通过data:字段逐行推送。浏览器提供原生EventSource接口，断线后还能自动重连。

不过EventSource只支持 GET 请求，无法携带复杂请求体。生产中常以fetch配合ReadableStream读取分块响应，从而获得 POST 能力与更细的流控。

服务端推送的通常是 SSE 文本或原始令牌。前端需要对缓冲区做增量切分，按\n\n切分事件，再按data:前缀提取有效载荷。

当令牌累积成 Markdown 时，难点出现了：一段未闭合的代码块或表格，不能直接交给渲染器。错误的解析会让界面在生成中途出现结构坍塌。

综上，消息从发起到渲染要过三关：先把 SSE 文本按\n\n切事件、按data:取载荷；再对累积的 Markdown 做未闭合围栏与表格保护，避免生成中途结构坍塌；最后才交给渲染器做最小化更新。把这三关守住，流式渲染才既快又不会散架。

三、生产级流式渲染组件

下面给出一个基于fetch与ReadableStream的流式控制器。它包含超时控制、解码容错、取消订阅和并发安全，能够支撑真实的生产环境。

// 流式对话控制器：负责拉取令牌并驱动增量渲染 // 为什么不用 EventSource：它需要 GET 且无法携带复杂请求体 export class StreamChatClient { private controller: AbortController | null = null; private decoder = new TextDecoder('utf-8'); // 累积缓冲区：SSE 事件可能被 TCP 分包，需要跨 chunk 拼接 private buffer = ''; /** * 发起流式对话 * @param onToken 每收到一段增量文本时回调，用于驱动渲染 * @param signal 外部可取消信号，避免组件卸载后仍在写入 */ async send( prompt: string, onToken: (delta: string, full: string) => void, options: { timeoutMs?: number } = {} ): Promise<string> { const timeoutMs = options.timeoutMs ?? 30_000; this.controller = new AbortController(); // 超时控制：大模型偶发卡顿会导致连接挂起，必须主动断开 const timer = setTimeout(() => this.controller!.abort(), timeoutMs); try { const res = await fetch('/api/chat/stream', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ prompt }), signal: this.controller.signal, }); // 异常响应必须提前抛出，否则会静默进入流读取 if (!res.ok || !res.body) { throw new Error(`流式通道异常：HTTP ${res.status}`); } const reader = res.body.getReader(); let full = ''; while (true) { // 网络抖动可能让 read 抛异常，需在外层捕获并兜底 const { done, value } = await reader.read(); if (done) break; this.buffer += this.decoder.decode(value, { stream: true }); // 按 SSE 事件边界 \n\n 切分，保证每条 data 完整 const segments = this.buffer.split('\n\n'); this.buffer = segments.pop() ?? ''; for (const seg of segments) { const line = seg.replace(/^data:\s*/, '').trim(); if (line === '[DONE]') continue; try { const payload = JSON.parse(line); full += payload.delta ?? ''; onToken(payload.delta ?? '', full); } catch { // 单行解析失败不应中断整轮对话，仅跳过该片段 console.warn('跳过无法解析的流片段'); } } } return full; } catch (err) { // 用户主动取消属于正常交互，不应上报为错误 if ((err as Error).name === 'AbortError') return ''; throw err; } finally { clearTimeout(timer); this.controller = null; } } // 组件卸载或用户停止时调用，避免内存泄漏与竞态写入 abort() { this.controller?.abort(); } }

在 React 中，我们把它封装成自定义 Hook，并用useRef持有完整文本，避免每次增量触发整树重渲染。

四、背压、断流与重连：弱网环境的三道关

流式渲染不是没有代价。最容易被忽视的是背压问题：当大模型生成速度远快于浏览器渲染速度，缓冲区会持续膨胀，最终触发内存压力。某内容平台曾因模型推理突发加速，3 秒内堆了 5MB 文本，前端直接卡死。

解决思路是做渲染节流。我们并不逐字setState，而是把增量累积到微任务队列，按固定帧率（如每 50 毫秒）批量提交一次视图更新。

断流是另一个真实风险。弱网环境下fetch长连接可能静默中断，且不会触发error事件。此时需要前端主动检测心跳：若超过阈值时间未收到新令牌，就发起重连并携带已生成的偏移量。

重连必须携带上下文。若服务端支持从指定偏移续传，前端应回传full文本长度，避免答案重复拼接。若不支持续传，则需要在 UI 上明确提示"已中断"。

必须清醒认识到方案边界。SSE 与fetch流在部分老旧浏览器上兼容性不足；超大响应会长期占用连接，导致并发连接数耗尽。对于超长文档生成，应改用异步任务加轮询拉取，而非死守单条流。

最后，流式渲染对无障碍体验也有要求。屏幕阅读器需要感知"内容正在生成"，应当在容器上设置aria-busy并在结束时切换状态。

五、总结

大模型流式对话界面的核心，是把首字延迟与渲染稳定性同时压到最低。SSE 与fetch流式读取，天然适配服务端单向推送的语义。

实现时务必补齐超时控制、解码容错、取消订阅与并发安全。增量渲染应采用节流合并，避免逐字触发重渲染。

弱网环境需主动检测断流并支持偏移续传。超长响应应切换为异步任务模式，避免连接长期占用。

落地路线建议：先以fetch流打通主链路，再补充超时与重连，最后引入渲染节流与无障碍标注。这条路在头部对话产品、内容平台、AI 助理里都跑通过，回报是值得的。