01

60 秒回答模板

前端 AI 输出流式返回时，如果主要需求是服务端把 token、状态和引用持续推给浏览器，SSE 通常更简单合适；如果需要浏览器和服务端持续双向通信、实时控制、多路会话或低延迟互动，WebSocket 更合适。SSE 基于 HTTP，浏览器有 EventSource，天然适合单向文本事件流，穿透代理和网关更容易，也有自动重连机制；缺点是主要单向、请求头和鉴权方式受浏览器限制、取消和背压能力有限。WebSocket 建连后双向通信能力强，适合语音交互、实时协作、模型中途控制、多路工具事件等，但连接管理、心跳、重连、负载均衡和代理兼容更复杂。AI 文本输出默认可优先 SSE，高交互或复杂控制场景再选 WebSocket。

考点 普通 AI token 单向输出更适
难度 真实面经题
回答目标 判断 AI 流式传输方案
02

深入解析

01

先看通信方向

AI 文本输出最常见模式是用户提交请求后，服务端持续推送 token、阶段状态、引用和结束事件。这是典型单向流，SSE 就很贴合。如果客户端还要频繁发送中途控制、音频帧、协作状态或多路事件，WebSocket 才更有优势。

02

SSE 简单且贴合 token 流

SSE 使用普通 HTTP 响应流，前端可以用 EventSource 或 fetch stream 处理逐步到达的数据。它适合文本 token、进度事件、引用信息和结束信号，部署上通常更容易通过公司网关、CDN 和代理。

03

WebSocket 更适合双向实时

WebSocket 在建立连接后可以双向收发消息，适合实时语音、多人协作、用户中途修改指令、模型执行过程控制、工具调用事件回传等场景。但它需要额外处理心跳、断线重连、连接迁移、负载均衡和服务端连接资源。

04

鉴权和取消要提前设计

SSE 的浏览器 EventSource 对自定义 header 支持有限，常见做法是 cookie、短期 token 或用 fetch stream 替代。取消生成时可以关闭连接并通知后端停止任务。WebSocket 则要在握手和消息级别做鉴权，并处理连接关闭后的任务清理。

05

重连和幂等影响体验

SSE 有自动重连和 last-event-id 思路，但 AI 生成流是否能断点续传取决于后端任务设计。WebSocket 也要设计重连后的会话恢复。无论哪种方式，都要避免重连后重复生成、丢失结束事件或 UI 状态错乱。

06

选择还要看基础设施

实际选型还受网关超时、代理缓冲、浏览器连接数、移动网络、服务端连接成本和监控能力影响。面试里可以给出结论：普通 AI 文本输出优先 SSE；需要强双向、实时控制或复杂事件通道时选 WebSocket。

03

易错点

  • 只说 WebSocket 更高级，所以所有流式输出都用 WebSocket。
  • 忽略 AI 文本输出多数是服务端到客户端的单向 token 流。
  • 没有考虑网关、代理缓冲、连接数和部署复杂度。
  • 不设计取消和后端任务清理，关闭前端连接后模型仍在跑。
  • 断线重连后没有处理重复 token、丢事件和会话恢复。
  • 把鉴权只放在前端，忽略服务端连接和消息级校验。
04

面试官追问

SSE 断线重连后如何避免 UI 重复展示 token？

因为大多数 LLM 输出是服务端持续推 token、客户端接收展示，天然是单向流。SSE 基于 HTTP，EventSource 支持自动重连，穿透代理和服务端实现通常更简单。

为什么 EventSource 的鉴权会比普通 fetch 麻烦？

WebSocket 适合需要强双向实时交互的场景，比如语音流、协同编辑、实时控制、多路事件、客户端持续发送上下文或需要低延迟双向协议。普通文本 token 输出未必需要。

AI 输出中途取消时，前后端分别要做什么？

SSE 的 EventSource 可以自动重连，但业务上还要带 conversationId、messageId、lastEventId 或 offset，让服务端能从正确位置续传或安全结束，避免重复显示。

代理缓冲会如何影响 SSE 的流式体验？

可以通过关闭连接、发送取消请求或用独立 HTTP API 通知服务端停止生成。SSE 本身是单向的，取消通常需要额外控制接口。

WebSocket 在服务端资源管理上有哪些挑战？

长连接鉴权、CSRF、跨域、代理缓冲、心跳、超时、限流、断线重连、消息顺序和前端内存清理都要处理；否则流式体验会不稳定。

如果要做语音实时对话，你会继续用 SSE 吗？为什么？

可以用流式分段时间、首包时间、断连率、重连成功率、消息丢失率、取消成功率、端到端延迟和用户感知等待时间来评估。