前端流式响应模式
前端接收流式响应时的常见模式，包括 SSE、Fetch Streams 和 WebSocket 及其适用边界。
#tech / dev / frontend
#type / synthesis
#status / growing
[!info] related notes
前端流式响应模式
流式输出不是一个具体 API，而是一类前端接收增量响应的模式集合。
一句话定义
前端流式响应模式，核心是在响应未完全结束前就开始消费增量数据，并持续更新界面。
常见方案
SSE
- 服务端单向推送
- 更适合大模型逐字输出和通知流
Fetch Streams
- 更灵活地消费响应流
- 适合自己控制 chunk 解析和状态管理
WebSocket
- 双向实时通信
- 更适合复杂状态同步和双向互动
怎么选更实用
- 单向文本流优先考虑 SSE 或 Fetch Streams
- 双向强交互再考虑 WebSocket
前端需要注意什么
- chunk 合并策略
- 中断和重试
- 状态机设计
- 渲染频率控制
最短记忆方式
先判断是不是单向文本流，再决定用 SSE、Streams 还是 WebSocket。
面试要点
来自 sse-vs-websocket-for-ai-streaming-interview-question 的面试视角整理。
一句话回答
如果是大模型逐字输出这类服务端单向文本流场景，SSE 通常更轻量也更贴近需求；如果需要更复杂的双向实时控制、状态同步或协作交互，WebSocket 更合适。
最稳的回答主线
- 先判断是不是单向文本流
- 再判断客户端是否也需要持续上行
- 最后补基础设施和复杂度成本
可以怎么展开
- AI 回复逐字输出通常是 server -> client 单向流，SSE 足够且简单
- 如果还要做复杂双向控制、协同编辑或实时状态同步，WebSocket 更合适
- SSE 基于 HTTP，更轻；WebSocket 更灵活，但维护成本更高
面试里最好补的一句
协议不是越强越好，而是看业务是不是需要双向高频互动。
常见误区
- 只因为 WebSocket 更强就默认选它
- 只说协议能力，不说实际维护成本和基础设施兼容性
- 把普通请求响应和流式响应混在一起回答
可能追问
- SSE 的限制有哪些
- Fetch Streams 和 SSE 的关系是什么
- AI 聊天为什么经常优先 SSE
最短记忆方式
单向文本流优先看 SSE，复杂双向互动再看 WebSocket。