流式输出（Streaming）这个概念，在AI对话应用里越来越常见，但很多人其实并不清楚它背后的工作原理——为什么同样是请求一次，有些页面能一个字一个字往外蹦，有些却要等半天才吐出一整段？这背后不是玄学，而是一套成熟的传输协议和数据处理逻辑。

从HTTP长连接到数据分块

传统的一次性请求（如stream: false，客户端发送请求后，服务端必须等整个响应体生成完毕，再一次性返回给客户端。用户看到的效果就是“转圈圈”，然后突然出现一大段文字。而流式输出则利用了HTTP/1.1的分块传输编码（Chunked Transfer Encoding），服务端可以边生成边发送数据块，客户端边接收边渲染。这种模式下，第一个字节的Content-Length头部不再需要，取而代之的是Transfer-Encoding: chunked。

具体到OpenAI的API，当你设置stream: true时，服务端会通过服务器推送事件（Server-Sent Events, Events, SSE）来推送数据。SSE是一种轻量级的单向通信协议，基于纯文本，格式非常简单：每一条消息以data: 开头，后面跟data:开头，后面跟着JSON数据，最后以两个换行符nn结束。例如：

data: {"id":"chatcmpl-xxx","object":"chat.completion.chunk","choices":[{"delta":{"content":"你"}}]}

data: {"id":"chatcmpl-xxx","object":"chat.completion.chunk","choices":[{"delta":{"content":"好"}}]}

data:}]

data: [DONE]

当收到[DONE]时表示流结束。客户端（如浏览器）通过EventSource或fetch的ReadableStream接口逐行读取这些数据，解析出delta.content字段，然后追加到显示区。这就是“打字机效果”的底层真相——不是前端模拟，而是真正的逐token生成。

为什么流式输出能提升体验？

从用户体验角度看，人类对延迟的容忍度极低。研究表明，超过2秒的响应时间2秒的200毫秒响应就会让人感到“卡顿”，而超过2秒就会产生焦虑。传统非流式模式下，一个长回答可能生成需要5-10秒，用户只能盯着旋转的加载图标干着急。流式输出将这段等待时间“分解”成多个微小的更新，用户看到文字一个个出现，大脑会认为系统正在“思考”，从而大幅降低感知延迟。

从技术实现角度看，流式输出还能带来一些带来两个解决痛点：

• 提前终止提前终止**：如果用户发现回答方向不对，可以立即点击停止按钮，中断请求，避免浪费token。非流式模式下，即使中途取消，服务端可能已经生成了大量无用数据。
• **资源释放：服务端不需要在内存中缓存中保存整个响应完整体，内存占用更低，尤其适合高并发场景。

实际开发中的坑与优化

接入流式输出并不是简单地设置stream: true就行。客户端需要处理断线重连——如果网络不稳定，可能收到一半就断了，需要记录已接收的token，下次请求时带上position参数让服务端续传。另外，解析SSE数据时要注意换行符的兼容性，不同操作系统可能混平台的换行符（rn vs nn`）可能导致解析失败。

还有一个容易被忽略的点：速率控制。流式输出时，每个chunk可能包含多个token，也可能只有一个字。如果前端每收到一个chunk就立即更新DOM，频繁的重绘会导致页面卡顿。合理的做法是使用requestAnimationFrame或设置一个缓冲区，每16ms批量更新一次，既保证流畅性又降低CPU开销。

不是所有场景都适合流式

流式输出虽然香，但并非万能。比如在批量处理、数据导出、或需要严格顺序保证的场景下，非流式反而更简单可靠。另外，SSE本身是单向的，如果客户端需要向服务端发送额外控制指令（比如“停止生成”），则需要配合WebSocket或额外的HTTP请求来实现。

说到底，流式输出的核心原理并不复杂——不过是把一次大的“发送-接收”拆解成多次小的“推送-消费”，但在工程实现上，细节决定了体验的优劣。下次。下次你看到AI一个字一个字往外蹦时，不妨想想背后那堆data:行和chunked编码，它们才是真正让对话变得“活”起来的关键。