企业官网建设流程全解析

让大模型"边想边说"的SSE，到底在传输什么？

第一次接大模型流式输出的时候，我盯着终端里逐字蹦出来的文字，脑子里冒出一个疑问：明明是一次HTTP请求，为什么响应能像流水一样断断续续地到？后来仔细翻了协议规范才发现，秘密全在响应头里那行Content-Type: text/event-stream——它背后的协议叫SSE，全称Server-Sent Events，服务端推送事件的HTTP标准方案。大模型流式输出的底层原理，说穿了就是一套"HTTP长连接上跑事件流"的机制。

这篇东西没有高深晦涩的数学推导，也没打算把RFC 2616搬来逐条念。我会从实际开发的角度出发，把SSE协议拆开看：它和大模型"打字机体验"之间是什么关系、数据在网络上到底长什么样、后端怎么发、前端怎么收、中间的反向代理又为什么经常"捣乱"。无论你是在搭OpenAI兼容接口，还是在用FastAPI写本地推理服务的流式转发，又或者只是好奇前端那行getReader()拿到的是什么，这篇都适合你。

1. 为什么要"流式"：大模型场景里的体验刚需

1.1 从"等30秒"到"边想边答"

先说一个最简单的现象。你调用GPT或DeepSeek的接口，如果不用流式，就得等模型把整段回答全部生成完，HTTP响应才返回。这个过程有多久？依我的实测，普通长度的回答，总生成时间在5到20秒之间，复杂一点的任务甚至奔着30秒去。用户那边看到的是什么？一个转圈圈加载条，转得人心慌。

更要命的是，大模型生成token的时间曲线不是线性的。首token延迟（生成第一个字的时间）通常只有几百毫秒到2秒，后续每个token的间隔也就几十毫秒。也就是说，模型在1秒内就能"开口"，但把整段话说完要20秒。用户白白在那干等19秒，而这19秒里内容其实一直在生成，只是被接口挡在水管闸门后面了。

流式输出直接把这道闸门打开。后端每生成一个token（或者一小批token），立刻顺着连接推给前端。于是用户看到的第一行字在1秒内就出现了，然后是第二行、第三行，整个体验从"加载中"变成了"打字机"。对习惯了即时反馈的人来说，这不仅是观感问题，还会直接影响他们对"智能"的感知——一个会边想边说的助手，远比一个憋半天再甩一大段的盒子更像真人。

1.2 HTTP轮询方案为什么救不了场

可能有人会想：那我不改接口结构，仍然用普通HTTP，只是前端每隔100毫秒轮询一次，模拟流式效果行不行？行，但从工程角度看相当不划算。

轮询的本质是重复发请求。每100毫秒一次，20秒就是200个请求，其中绝大多数拿到的都是"还没有新内容"这个结论。请求本身有HTTP握手的开销，有网络往返延迟，还会给网关带来可观的并发压力。稍微算一下账：100个用户同时在用，轮询方案每秒就要扛1000次请求，而真正的流式连接只有100个活跃长连接，哪个对运维更友好一目了然。

更麻烦的是轮询的乱序问题。假设你分两次轮询，第一次拿到了第1到5个token，第二次拿到第6到10个。可如果中间某次请求出现了重试、超时、或者网关把两次响应合并了，前端就得处理"缺段""重复""乱序"三类情况。这本质上是在用HTTP的短连接语义拼接"流"的效果，属于拿锤子拧螺丝，能用但别扭。

SSE的思路完全不同：它只发一次HTTP请求，然后服务器在这条连接上源源不断地推送事件，连接的寿命由业务决定而不是由请求-响应的闭合规则决定。数据顺序天然就是生成的顺序，不需要前端拼图。

1.3 SSE怎么跑在HTTP这条老路上的

SSE的全称是Server-Sent Events，名字直译就是"服务端发送的事件"。它不是一个新协议，而是建立在HTTP之上的、由W3C标准化的一套推送方案。它的关键动作有两个：

• 服务端在响应头声明Content-Type: text/event-stream，告诉客户端"这条响应我打算持续开着，不是等你说完就关"。
• 服务端以文本块的形式往连接里写事件，每个事件之间用空行分隔，事件内容由若干个字段: 值构成。

因为底层就是HTTP，所以它不用像WebSocket那样先发一次特殊的握手请求、完成协议升级。任何能发HTTP请求的客户端——浏览器、curl、Python的requests、Node的fetch——理论上都能消费SSE流。这也是大模型服务商（从OpenAI到国产模型的API）普遍选择SSE做流式输出的原因：兼容面极广，几乎不需要改基础设施。

理解到这一层，"流式输出的底层原理"这顶帽子就摘掉一半了。剩下一半要看懂网上真正跑的字节长什么样。

2. 动手拆协议：SSE在网络上到底长什么样

2.1 一段响应搞定所有：text/event-stream

我用一个最朴素的例子演示。假设服务端要发三个事件给客户端，内容分别是"你好""我是AI""再见"。响应报文大致是这个样子：

HTTP/1.1 200 OK Content-Type: text/event-stream Cache-Control: no-cache Connection: keep-alive data: 你好 data: 我是AI data: 再见

注意几个细节：

• Content-Type必须是text/event-stream，这是客户端识别"这是SSE流"的唯一标志。
• Cache-Control: no-cache是标准建议，防止中间缓存节点把流内容囤起来导致前端收不到增量。
• 每个data:后面跟的是这一条事件的内容，事件与事件之间必须有一个空行，这个空行就是分帧符。
• 连接不会在再见之后立刻关闭，只有服务端主动断开连接，客户端才会知道"流结束了"。如果你想告知"正常结束"，业内习惯是在流末尾写一个data: [DONE]之类的特殊约定（OpenAI就是这么做的），也可以直接关连接让前端走onclose。

有人可能会拿curl实测：curl -N http://your-api/stream，看输出确实是多行data:文本。这已经足够说明问题——SSE在网络层就是"一段永不结束的HTTP响应体"。

2.2 消息边界：空行分隔的"事件流语义"

SSE的格式里没有JSON容器、没有Length字段，它用换行 + 空行来划分事件边界。前端解析时其实是按行读，读到空行才认为一个事件完整了。

看这个例子：

data: 第一行内容 data: 第二行内容

这两行data:属于同一个事件。SSE规范规定，多个data:字段会以换行符拼接成同一条事件的内容。所以前端收到的message.data是"第一行内容\n第二行内容"。

这个逻辑对换行敏感。写服务端代码时，如果漏了在事件末尾加空行，前端会一直傻等，认为事件还没结束。我在写第一版流式接口时就踩过这个坑：curl能一路看到数据，但浏览器的onmessage死活不触发——排查半天，发现是生成器里每条消息后面没追加\n\n。

这里也顺带解释一个容易混淆的点：事件（event）和消息（message）在SSE上下文里基本是同一个意思，可以互换理解。规范里正式叫法是"事件"，浏览器API里的事件名是message。

2.3 命名事件、断线重连与Last-Event-ID

data只是SSE的一个字段，完整的字段体系还包括：

在长任务场景里，id和retry尤其关键。想象你正在用大模型API生成一篇长文，生到一半网络闪断了。如果服务端支持用id标记每个事件，浏览器会自动带上Last-Event-ID请求头重新发起连接。服务端拿到这个ID，就知道"这哥们已经收到第N个token了"，可以从N+1接着发，不用重新生成一遍。这在大模型场景不算特别常见（大部分厂商是重新开始），但做私有化部署时，这个机制做得好是很亮眼的体验优化。

event字段则适合给流里的不同内容打标签。比如推理过程和最终答案是两类内容，服务端可以一边发event: reasoning\ndata: ...，另一边发event: answer\ndata: ...，前端用两个监听器分开处理，渲染区域也能拆成"思考过程区"和"正式答案区"。用不用看业务需要，但知道有这招，设计接口时会从容很多。

2.4 规范和格式的细节清单

我把自己实践过程中最常用的格式约定整理成了一份速查表，你可以直接对照使用：

• 每条字段写成字段名: 字段值，冒号后面有一个空格，空格分隔再多个的写法不适用。
• 每条事件以空行结束。如果忘了空行，浏览器端的EventSource会一直不触发回调。
• 不要用\r\n之外的换行符？实际上规范支持\r\n、\n和\r，但为了跨平台稳妥，服务端代码统一输出\n就够。
• 查询参数的URL编码要考虑：如果data:里是JSON，字符串里不能出现裸换行（JSON本身不允许），需要压缩成单行JSON串。
• 流内不能有Content-Length，因为长度未知。实际响应头通常会省略该字段，配合chunked传输。

3. SSE、WebSocket、gRPC流：大模型场景怎么选

3.1 为什么大模型服务商几乎都选了SSE

如果你打开OpenAI的API文档，会发现流式模式叫stream=true，返回的content-type就是text/event-stream。国内主流大模型API基本上也是这个套路。为什么大家不约而同选了SSE，而不是功能更强大的WebSocket？

我理解的核心原因有三个：

• 单向性足够。大模型的交互链路是：用户先发一次请求（带prompt），服务端持续返回内容。这是一个典型的"客户端发起、服务端单向下行"的模式，整个交互周期里客户端不需要往连接里写东西。WebSocket的双向能力在这里其实用不太上。
• 代理友好。SSE是标准HTTP，能过HTTP/1.1的反向代理、负载均衡，不需要像WebSocket那样考虑Upgrade握手、跨域预检、连接状态在代理层的额外管理。很多老旧网关甚至不需要改配置就能透传SSE（只要别开缓冲）。
• 浏览器原生支持。前端一个new EventSource(url)就搞定了，自带重连，不需要引入第三方SDK。对做演示项目、快速原型来说，这是最省事的路。

3.2 SSE真正短板：单向、连接数、代理缓冲

SSE要是十项全能，WebSocket大概早就被人遗忘了。它的真实短板得摆到台面上看：

• 单向。服务端不能接收来自这条连接的新消息。如果用户想在生成过程中"打断"或者"追加指令"，还是得发新的HTTP请求去触达服务端。好在大多数大模型场景不需要打断——你顶多是在前端不渲染后续内容，而不是真在传输层把流掐断。
• 并发连接数限制。HTTP/1.1下浏览器对同一个域名的最大并发连接数大概是6个（各家略有不同）。如果你的页面同时开3个SSE流、再加载几张小图，分分钟把连接额度吃光。解决方案是HTTP/2（多路复用）或者给SSE单独配子域名。
• 代理缓冲。这是实际踩坑率最高的一项。Nginx默认会缓冲代理响应，把一小段一小段的数据攒成完整大块才丢给客户端——流式接口遇上它，效果直接退化成"10秒一蹦字"。必须显式关闭缓冲，详见后面第5节。

3.3 正确的选型姿势

我的个人判断是这么个标准：

• 服务端单方面给客户端推数据、数据量大且连续 →SSE。
• 客户端与服务端频繁双向交互，比如实时协同编辑、聊天室、在线游戏 →WebSocket。
• 需要强类型、多路复用、跨语言RPC体系 →gRPC流（在大模型推理框架内部挺常见，比如vLLM和TGI之间）。
• 已经有HTTP/2基础设施、想减少连接数 →SSE over HTTP/2，或者直接用WebSocket套一层。

大模型API场景，说实话90%的流式返回用SSE就够了。做私有化部署时，如果推理引擎用的vLLM内部是gRPC，那也是内部通信的事，你暴露给客户的API仍可以转成SSE。流式协议之间没有绝对的优劣，核心是匹配传输模型。

4. 从后端到前端的全链路SSE实现

4.1 服务端：用FastAPI写一个流式接口

假设你的上游是本地推理引擎（或OpenAI兼容API），你要做的是把那边的token流转发出来。直接给一段可运行的FastAPI实现：

import asyncio import json from fastapi import FastAPI from fastapi.responses import StreamingResponse app = FastAPI() def mock_token_stream(text: str): """模拟一个逐token产出内容的上游源，替换成真实的模型调用即可。""" for char in text: yield char async def sse_generator(): full_text = "你好，我是流式AI。这个演示会逐字输出内容。" for token in mock_token_stream(full_text): # 每次只产出一个 token，按 SSE 格式包一层 payload = json.dumps({"choices": [{"delta": {"content": token}}]}, ensure_ascii=False) yield f"data: {payload}\n\n" # 模拟模型推理间隔，真实场景会把上游的等待时间自然透传出来 await asyncio.sleep(0.05) @app.get("/v1/chat/stream") async def chat_stream(): return StreamingResponse( sse_generator(), media_type="text/event-stream", headers={ "Cache-Control": "no-cache", "X-Accel-Buffering": "no", # 告诉Nginx等代理别缓冲，后文细说 }, )

这里有两个点要特别说明。

第一，StreamingResponse里的generator是一个异步生成器，FastAPI会持续从里面取数据写入响应。每写一次，数据就通过HTTP chunked传输推给客户端。yield f"data: {payload}\n\n"这行是整个流式输出的灵魂：它把JSON包装成SSE事件，末尾的空行标记事件结束。

第二，ensure_ascii=False一定要带上。如果默认True，中文会被转成\u4f60\u597d这种形式，内容没错但前端想实时渲染就会遇到"一个汉字显示成6个字符"的尴尬，而且可读性极差。

如果你用的是Flask，思路也一样，只是不用StreamingResponse，改成在视图函数里返回一个生成器，配合响应头的content-type设置即可。

4.2 中间层：Nginx关闭缓冲，别让令牌被"团购"

服务和用户之间隔着一层Nginx的话，十有八九会遇到"流式接口变傻"的问题。Nginx收到上游发来的数据，默认等攒够buffer（通常4KB/8KB）或者等上游关闭连接，才一次性转发给下游。对于SSE，这意味着用户看到的是"卡几秒、跳一大段"。

解决办法在Nginx配置里：

location /v1/chat/stream { proxy_pass http://backend_upstream; proxy_buffering off; proxy_cache off; proxy_read_timeout 300s; proxy_set_header Connection ''; proxy_http_version 1.1; chunked_transfer_encoding on; }

• proxy_buffering off直接关闭代理缓冲，数据逐块透传。
• 代码里那个X-Accel-Buffering: no响应头，是给Nginx看的"这条响应别缓冲"的显式指令。两处都写上，双保险。
• proxy_read_timeout 300s是防超时断开。SSE连接可能长时间没有新数据（比如模型在思考），默认的60秒可能就被掐断了。
• Connection: ''配合proxy_http_version 1.1，是为了让上游和代理之间也能维持长连接。

Caddy的处理更简单，默认不缓冲，基本不用额外配置。如果是云厂商的SLB/ALB，去控制台把"响应缓冲"或"HTTP响应压缩"关掉。我遇到过阿里云SLB把SSE当普通响应缓冲了的情况，症状极其诡异——浏览器偶尔收到完整内容、偶尔卡住。

4.3 前端：用fetch的ReadableStream逐行解析

浏览器端的EventSource虽然原生支持SSE且自动重连，但它有个限制：只能GET请求，没法带Authorization头（除非用token放在query里）。这在调用很多需要鉴权的大模型API时很别扭。

更通用的方案是用fetch + ReadableStream。下面是一段兼容SSE格式的解析逻辑：

async function parseSSE(response) { const reader = response.body.getReader(); const decoder = new TextDecoder('utf-8'); let buffer = ''; while (true) { const { value, done } = await reader.read(); if (done) break; buffer += decoder.decode(value, { stream: true }); // SSE事件按空行分隔，切出完整事件再逐条处理 const lines = buffer.split('\n'); buffer = lines.pop(); // 最后一段可能不完整，留到下一轮 let dataLines = []; for (const line of lines) { if (line === '') { // 空行表示一个事件结束 if (dataLines.length) { const payload = dataLines.join('\n'); handleEvent(payload); // 你的业务回调 dataLines = []; } } else if (line.startsWith('data:')) { dataLines.push(line.slice(5).trimStart()); } } } }

几个关键点：

• decoder.decode(value, { stream: true })解决中文编码的截断问题。网络包到达时可能把一个UTF-8字符切成两个chunk，不用stream模式会把字节顺序搞坏，出现乱码。这个参数等于告诉TextDecoder"字节还没全，别急着报错"。
• buffer.split('\n')然后最后一段留到buffer里，是典型的增量解析套路。不这样做，一次read返回的可能只是半行。
• 事件结束后dataLines.join('\n')可以通过event字段做分支。进一步处理时，很多API的SSE消息是data: {json}这种，JSON.parse之前务必去掉data:前缀。

不用EventSource，也就不用担心它不支持自定义请求头的问题。用fetch做流式时要注意，所有浏览器对response.body的读取都要求服务端返回了正确的content-type。如果你的接口返回的是application/json，某些浏览器可能直接放弃流式读取。

4.4 中文场景的坑：UTF-8分块乱码

这是多语言场景特有的坑，值得单独拎出来。SSE是文本协议，数据在网络上以字节形式传输，而中文在UTF-8下占3个字节。TCP/IP和HTTP/2的分帧并不保证"一个字符的3个字节落在同一个TCP段里"，于是可能发生这样的情况：后端发了"你"字的三字节的一部分，前端恰好在这个位置切了chunk，页面渲染就出现一个�。

解决方式就是我前面说的，前端解析时用TextDecoder('utf-8', { stream: true })，它会智能地把不完整的字节序列留在内部缓冲里，凑齐了再输出字符。如果在前端框架里做SSE解析，记住这个参数比记住SSE格式还重要——我见过好几个项目乱码，排查半天发现就是解码方式不对。

另一个小建议：服务端发送时尽量整字节地发送一个完整的UTF-8字符，前端省心，后端也不费什么劲。生成式模型出来的通常本来就是完整字符，不太容易踩这个坑，但如果你做了某种字节级的token压缩、或中间有转码代理，就要特别小心。

5. 上线前必看：流式接口生产环境避坑实录

5.1 常见问题速查表

我把实操中反复遇到过的SSE问题整理成一张表，排查时按图索骥即可：

5.2 心跳与超时：空转连接怎么保活

SSE连接如果长时间没有数据，代理节点和浏览器都可能有超时清理策略。大模型场景里有一种常见情况：模型进入深度思考，可能一两分钟内没产出任何token（如果你的架构是"全部构思完再输出"，这就更明显）。这时连接空转，很容易被中间链路误杀。

业界标准做法是发注释行当心跳：

async def heartbeat(interval=15): while True: yield ": heartbeat\n\n" await asyncio.sleep(interval)

以冒号开头的行在SSE规范里是注释，客户端会直接忽略，既不会触发message事件，也不影响事件流语义。但它在网络层是"活跃数据"，能让Nginx、SLB之类的节点认为连接还是活的，不会因为闲置而回收。

几套主流方案里，retry字段也能帮上忙：断开后客户端会按这个毫秒值等待再重连。如果服务端知道自己的流会长时间静默，可以把retry设得短一点，比如15秒，让前端更快恢复连接。

5.3 流控：别让一个慢用户拖垮整个服务

SSE长连接的资源占用比普通短请求高。同样一小时内，短请求发完就释放连接，而SSE连接可能保持几分钟甚至半小时。如果并发用户数大、又不做任何限制，服务器的连接数、内存、句柄数都可能告急。几个相对实用的策略：

• 限流：在网关或应用层按用户维度限制并发流数量，比如"同一token最多同时3条流"。
• 闲置超时：超过N分钟没有下行数据的连接自动断开，让客户端重连续传。
• 背压处理：大模型推理速度快于网络发送速度时，服务端不能一股脑把数据塞进内核缓冲区。实际做法是控制生成器循环的节奏，比如按批次休眠（asyncio.sleep(0.01)），或者用容量有限的队列衔接推理线程和发送协程。
• 断线续传（可选高级功能）：配合id字段实现，重连时带上Last-Event-ID从断点续发，长文生成场景体验提升明显。

我见过一个部署案例：内网带宽有限，服务端每秒钟产出的token远超网络吞吐，结果负责发送的协程被疯狂积压，内存飙到几百MB。加了二级队列缓冲后，一切恢复正常。记得，流式接口不只是"把生成器接上去"，后端的生产速度和消费速度必须匹配。

5.4 实测记录：用openai-sdk时如何拿到真正的流

如果你直接用OpenAI官方Python SDK，流式模式通常长这样：

from openai import OpenAI client = OpenAI(api_key="your-key", base_url="your-endpoint") response = client.chat.completions.create( model="your-model", stream=True, messages=[{"role": "user", "content": "讲个笑话"}], ) for chunk in response: delta = chunk.choices[0].delta.content if delta: print(delta, end="", flush=True)

SDK内部发出去的是普通HTTP请求，请求头里带stream=true，返回响应后SDK再把text/event-stream的文本逐事件解析出来，转成Python对象让你迭代。如果你要自己造一个兼容OpenAI格式的流式API，关键就是把你输出的event结构对齐成它约定的格式：

{"choices": [{"delta": {"content": "你"}, "index": 0}]}

把content字段换成增量文本，最后一个事件往往带finish_reason: "stop"。照着这个结构发，市面上几乎所有OpenAI兼容客户端都能直接消费你的流。

6. 更进一步：SSE的边界与流式方案的想象力

6.1 服务端到服务端：Python的SSE消费姿势

很多教程默认SSE的消费方是浏览器，但实际大量流式接口的下游是另一个服务。比如你在中间层做大模型网关，需要把上游的SSE流转发给下游系统，用Python就能直接读：

import requests resp = requests.get("https://api.example.com/v1/chat/stream", stream=True) for line in resp.iter_lines(): if not line: continue if line.startswith("data:"): payload = line[5:].strip() if payload == "[DONE]": break print(payload)

这里iter_lines()是requests库提供的按行迭代方法，天然适合SSE这种行协议。如果字节流被分包，requests内部会帮你攒行攒好了再说。实际用下来，比手动处理buffer + split要省心很多。

6.2 HTTP/2多路复用：SSE的并发瓶颈破局点

前面提到HTTP/1.1下浏览器单域名6连接的限制，会让同时开多个SSE流变得紧张。HTTP/2的多路复用允许在一个TCP连接里同时跑多个流，也就是说同一域名下的SSE数量不再受6条限制，配置得当甚至可以开几十条。

但这有个前提：你的反向代理和浏览器之间得真的走HTTP/2。如果是给浏览器提供API，一般要配合Nginx开启HTTP/2 + TLS（目前多数浏览器要求HTTP/2必须配TLS）；如果是服务端之间的通信，倒是简单许多，Nginx侧加http2 on;即可。

如果你的大模型应用要在页面上同时展示多个Agent的实时思考过程，这些流会同时打开。这时候HTTP/2几乎是必选项，不然单域名6连接分分钟耗尽。

6.3 从SSE到全双工：MCP与工具的流式落地

最近大模型圈很火的MCP（Model Context Protocol）场景里，流式输出也有了新角色：Agent在运行工具并返回结果时，可以用流式通道把中间过程实时推出。比如你让模型调用一个搜索工具，模型正在"翻阅资料"的状态、工具返回的中间片段、最终结论，都可以拆成不同类型的事件，用event字段区分，前端就能把这些过程渲染成"思考中→工具调用→输出结论"的完整时间线。

我实际试验过一种方案：Agent工具链执行到文件写入步骤时，通过SSE把写入进度（比如"正在写第300行"）实时推到前端；工具完全结束后再发一条event: done。效果比干等一个工具调用的最终结果好很多——用户至少知道"它没卡死，还在干活"。这类"流式输出内容到文件/工具状态回传"的需求，用SSE的命名事件实现起来非常顺手。

6.4 流式方案的发展不是"互相取代"

SSE、WebSocket、gRPC这些方案，本质上是传输模型的适配器，未来也不会是谁取代谁，而是按场景各就各位。SSE因为简单、标准、兼容面广，在大模型API这波浪潮里重新火了一把——它一直是那个最"省事"的选项。真正做架构的时候，也别嫌它功能弱，先把HTTP层用好，把缓冲关对，把编码处理好，大部分流式需求已经能覆盖得七七八八。

最后分享一个我自己形成的习惯：每写完一个流式接口，第一件事不是看前端页面，而是开一个终端用curl-N直接看裸的响应流。这个方法能绕过所有前端解析逻辑，一眼就分清问题是出在"服务端没发出来"还是"前端没解析对"。先确认上游的data:和空行是干净的，再排查下游的代理和编码，几乎能解决90%的SSE疑难杂症。流式调试这种活，越是基础的工具，越能救急。