从 SSE 到 LLM 流式输出：搞懂前端实时通信的两种姿势

一、为什么需要流式输出？

传统 HTTP 的痛点

传统 HTTP 请求-响应模型：
浏览器 服务器
│ │
│──── HTTP 请求 ───────────────→│
│ │
│ │
│ │
│ │
←──── 完整 HTTP 响应 ──────────│
├───────────────────────────────────────────────────────────────────────────────┤
再看问题。① 使用者体验差 → 等待 秒才看到任何内容 → 使用者以为页面卡死了 → "白屏"焦虑
② 服务器压力大 → 必须等所有数据准备好才能响应 → 大量数据积压在服务器内存中 → 并发时容易 OOM
③ AI 场景特别需要 → LLM 生成一个完整回答可能需要 - 秒 → 如果等完整回答再返回 →
使用者等 秒 → 如果边生成边返回 →
使用者 秒就看到第一个字 → 这就是 ChatGPT 打字机效果的原理

流式输出的本质

流式输出 = 把"一次性返回"拆成"分块返回"
传统方式的观点是，服务器： → 一次性发给浏览器
再看流式方式，服务器： → → → ... →
浏览器的观点是，逐个接收，实时显示
主要概念这方面，• chunk→ 流式传输的基本单位，像水管里的水，一段一段流过来每个 chunk 是部分数据，拼接所有 chunk = 完整数据。• stream→ chunk 的有序序列，有始有终，有打开有关闭。• 使用者模式→ 前端逐个接收 chunk。每收到一个就处理，流结束后做收尾工作。

两种流式输出场景

┌──────────────────────────────────────────────────────────────┐
│ 两种流式输出技术方向 │
├──────────────────────────────────────────────────────────────┤
│ ① SSE │
│ • 服务器主动推送 │
│ • 浏览器用 EventSource API 接收 │
│ • 基于 HTTP 长连接 │
│ • 场景：实时通知、股票行情、ChatGPT 打字机 │
├──────────────────────────────────────────────────────────────┤
│ ② LLM Stream API │
│ • LLM 生成的文本流式返回 │
│ • LangChain 的 model.stream │
│ • 基于 AsyncIterator │
│ • 场景：AI 对话、AI 写作、AI 代码生成 │
├──────────────────────────────────────────────────────────────┤
至于两者关系。• LLM Stream 是数据源
• SSE 是传输方式
实际使用中通常组合使用：后端用 LLM stream 获取 AI 输出，再通过 SSE 推给前端。

二、SSE：Server-Sent Events

SSE 原理

SSE = Server-Sent Events
主要原理这方面。→ 基于 HTTP 协议
→ 服务器保持连接不断开
→ 服务器持续推送数据给浏览器
→ 浏览器通过 EventSource 接收
工作流程图示的观点是，浏览器 服务器
| |
|── GET /stream ───────────────▶|
| |
|←── data: "你"
| ← 第 n 秒 |
| | |
| |
|←── data: "好"
| ← 第 n+1 秒 |
| | |…，|←── 数据结束 | ← 连续推送完成，关闭连接
说到关键点。① HTTP 连接保持不断开
② 服务端可以随时推送
③ 每个 `data:` 块就是一个 chunk
④ 浏览器通过 `onmessage` event 每个消息处理一次。

SSE 的三个响应头

SSE 必须设置三个关键响应头：
res.writeHead(200,{
'Content-Type': 'text/event-stream'。// 声明 SSE 协议，让浏览器进入流模式
'Cache-Control': 'no-cache',// 禁止缓存，保证每次都是最新的数据
'Connection': 'keep-alive',// 保持 TCP 长连接，不断开
说到});话说回来，说明，Content-Type: text/event-stream — 告诉浏览器这是 SSE 流。Cache-Control: no-cache — 防止旧缓存被
使用。Connection: keep-alive — 保持 TCP 长连，避免短连导致频繁重连。

SSE 数据格式

SSE 数据格式比较简单：
再看data，你好
从规则来看，① 每条消息以 "data:" 开头
② 消息内容跟在后面
③ 用 "
" 两个换行符表示消息结束
从例子来看。data: 第一行
// 单行文本
再看data，{"name":"张三","age":25}
// JSON 可选
说到data，行1
data的观点是，行2
// 多行文本合并为一条消息
为什么使用
而不是其他分隔符？因HTTP基于文本协议，自然对应消息体结束。也与HTTP头部与body分隔一致，兼容性好且易解析。

完整 SSE 服务端实现

// server.js — 原生 Node.js 实现 SSE
const http = require;const fs = require;const server = http.createServer => {
if {
const readStream = fs.createReadStream;readStream.on('error',err => {
res.writeHead;res.end，});res.writeHead;readStream.pipe;} else if {
res.writeHead(200,{
'Content-Type': 'text/event-stream'。'Cache-Control': 'no-cache','Connection': 'keep-alive',});话说回来，const words =;let index = 0;const timer = setInterval => {
if {
clearInterval;res.end，不过，// 所有数据发完，关闭连接
return;}
res.write，index++;},1000)，// 每秒推送一个字符模拟耗时操作
}
});server.listen => console.log);老实说，

代码解析的观点是。

• GET / 路由：返回静态 HTML 页面用文件读取直接写入 Response，也是单向文件流。
• GET /stream 路由：设置三大 Header 后通过 `setInterval` 模拟每秒产生一个字符，将其包装成 `data:` 格式并写入 Response。
• 当所有字符发送完毕后调用 `res.end`，完成长连生命周期。
• 实际业务可将 `setInterval` 替换为对 LLM 或数据库查询结果的异步迭代。

前端 EventSource 接收示例

EventSource API 小结：


新建实例即会自动开启长连；若断线会自动重连，无需手动管理 socket。

`onmessage` 每收到一条 `data:` 就触发一次实现打字机效果。

局限这方面，


只能 GET；话说回来，不能携带 Authorization 或自定义请求头。

无法携带 POST body。

如果需要复杂请求，可改用 fetch + ReadableStream 实现自定义协议。


从安全注意来看，使用 `innerText +=` 而非 `innerHTML +=` 防止 XSS 注入。


SSE vs WebSocket 对比表格：




对比维度
SSE
WebSocket 

基本特征 
通信方向 
单向 
双向 


协议类型 
基于HTTP 
#ffecec'

断线重连 
自动重连，无需手动实现 
#ffecec'>需手动实现

#cdefff>'API 类型'
#cdefff>'EventSource'
#ffecec'>WebSocket





HTTP 方法限制 '
GET 限制仅可 GET

 



...
-->
...

"