【面试真题拆解21】为什么用SSE做流式输出?和WebSocket有啥区别?

面试官问：

“你项目里用了SSE做流式输出，为什么选SSE？它的原理你知道吗？为什么不用WebSocket？”

为什么用SSE做流式输出？

一句话：

SSE 是为服务器单向给客户端推数据的场景量身定做的，完美匹配 AIGC 流式打字机的需求，开发简单、好用、运维成本低。

类比：

• • SSE 就像广播电台：电台单向给你播新闻、播音乐，你只能听，不能对着电台说话；
• • WebSocket 就像打电话：你和对方可以双向说话，你一句我一句，实时互动。

SSE流式输出的原理

SSE是Server-Sent Events（服务器发送事件），本质上是一条由服务器控制生命周期的持久化 HTTP 长连接，在数据推送周期内保持打开，不会像普通 HTTP 请求一样响应完成就立刻关闭。

完整的流程就是：

1. 1. 客户端发起请求

浏览器向服务器发起一个普通的HTTP GET请求，但请求头里要加 Accept: text/event-stream，告诉服务器：“我要接收流式数据，别给我返回普通网页”；

1. 2. 服务器建立长连接

服务器收到请求后，不立刻返回完整响应，而是保持这条HTTP连接一直打开，不关闭；

1. 3. 服务器持续推数据

服务器有新数据了（比如AI生成了一个字），就通过这条打开的连接，把数据推给客户端；

SSE 有固定的标准文本格式，每段数据以data:开头、\n\n结尾，刚好适配大模型逐 Token 生成的流式输出，后端生成一个 Token 就推一次，前端无需额外做格式解析，直接渲染成打字机效果；

1. 4. 客户端解析数据

浏览器收到数据后，自动解析，触发 onmessage 事件，前端把数据展示出来；

1. 5. 连接结束或自动重连

如果数据推完了，服务器就会主动关闭连接；

如果连接意外断开（非手动关闭、非服务器返回 204 状态码），SSE 自带自动重连机制，浏览器会自动重新发起请求，还会通过请求头Last-Event-ID带上最后接收的消息 ID，后端可据此补发丢失的内容，避免 AI 回答断句缺失，建立新连接后继续接收数据。

为什么不用WebSocket？

WebSocket 是为双向实时交互场景设计的，对于 AI 流式输出这个纯服务器单向推数据的场景，属于杀鸡用牛刀，额外增加了开发、运维成本，完全没有必要。