流式输出这东西说实话我第一次意识到它有多重要是在一次糟糕的等待体验里。那时候还不流行大模型但已经在做类似机器翻译的接口。用户点一下按钮要等三到五秒才看到完整结果。当时有人在页面上加了一个转圈动画但我心里很清楚用户不是没耐心而是“看不到进度”会让等待变得极其煎熬。后来换成流式输出边生成边显示用户等待体感直接砍半甚至有人反馈“好像变快了很多”——其实总耗时一点没变但体验就是完全两回事。从那时起我就觉得流式输出不是锦上添花的功能而是现代应用里决定用户体验档次的关键环节。这篇博文我想完整聊聊流式输出的原理、实操实现、以及我踩过的那些坑帮同样在做这类功能的人少走点弯路。1. 流式输出解决的核心问题与适用场景1.1 什么时候必须考虑流式输出流式输出专业点说叫 Streaming本质是把一次完整的网络响应拆成多个小块让服务器先推送一部分数据过来客户端立即处理渲染而不是等全部数据组装完毕才一次性返回。最常见的场景就是大模型对话。比如我本地部署过的开源模型生成一句几百字的回复如果需要十秒那么你盯着空白对话框等十秒和看到第一个字在0.5秒就冒出来、然后像打字一样逐渐生成完整内容体验差距是天壤之别。前者让人怀疑系统挂了后者让人感觉“AI在思考后开始回答”反而增加了透明度和信任感。再从更广的视角看适合流式输出的场景至少有三类LLM 对话与文本生成ChatGPT 这类应用的基本盘逐字逐句渲染生成内容。长耗时任务的任务进度反馈比如文件转码、视频处理、批量数据分析服务器处理需要几十秒到几分钟持续向客户端推送进度百分比和日志。实时日志与监控面板持续输出运行日志、指标变化类似命令行 tail -f 的效果适合运维和信息流类应用。这里有个容易被忽略的细节流式输出和普通长连接不是一回事。普通 HTTP 请求会等服务器完全处理完才返回响应而流式输出的关键是服务端可以在计算还没有结束时就“边算边发”。这背后依赖的传输机制我下面细说。1.2 等完整响应 vs 流式输出的用户体验差异我做过一个很直观的测试。把同一个大模型接口改成流式和非流式两种方式模拟用户点击发送按钮到完整结果渲染出来的整个过程统计用户感知到的“响应时间”。非流式模式下用户看到的是点击发送 → 转圈等待 → 十秒后整段文本突然出现。流式模式下点击发送 → 0.5秒后第一个字出现 → 持续逐字输出直到完整内容渲染。结果很有意思。用户的投诉和重新提问次数在非流式模式下明显更高。因为在等待期里用户会反复点击按钮、刷新页面、修改提问甚至误判“系统崩溃了”。而流式模式下用户知道系统“正在工作”能提前浏览已输出部分甚至在生成结束前就开始阅读整体等待感被大幅稀释。从技术指标来看流式输出优化的不是“总耗时”而是“首字节时间”TTFBTime To First Byte。如果一个接口的总耗时是十秒非流式的 TTFB 就是十秒流式可以压到 0.5~1 秒。用户对“快”的感知更多来自 TTFT首 Token 时间而不是总耗时。这是做用户体验优化时特别关键的一个认知转变。2. 流式输出的协议选型与底层原理2.1 传输层的三种方案对比流式输出不是新概念但不同落地方式的取舍差异很大。当前主流的方案有三类HTTP 分块传输、SSEServer-Sent Events服务器推送事件和 WebSocket。方案传输方向实现复杂度适用场景HTTP 分块传输Chunked服务端→客户端单向低文件下载、普通流式内容SSE服务端→客户端单向低LLM 流式回复、日志推送、通知流WebSocket双向通信高聊天室、协同编辑、实时游戏HTTP 分块传输是 HTTP/1.1 协议内置机制服务端不告诉客户端 Content-Length而是持续发送分块数据每个分块前都有十六进制长度标识最后以空块收尾。浏览器自动支持但普通开发者的 JS 代码不太好直接控制读取节奏一般靠 fetch 响应体流式读取。SSE 是基于 HTTP 的一种轻量级推送协议响应头的 Content-Type 是 text/event-stream服务端不断发送以data:开头、空行分隔的事件流。它的最大优势是浏览器原生支持EventSource API断线还能自动重连非常省心。大模型流式输出的标准格式其实就是 SSE 的变种。WebSocket 虽然能实现同样效果但双向通信意味着更强的实时交互能力和更高维护成本如果只是服务端单向推送给客户端用它反而“杀鸡用牛刀”。LLM 场景里用户提问是普通请求只是响应需要流式返回SSE 是最省事且最稳定的方案。2.2 SSE 协议的格式规范和核心要点SSE 协议看着简单但有几个细节如果不注意会在对接时踩大坑。先看一个标准的 SSE 流长什么样data: {message:你} data: {message:好} data: {message:} data: [DONE]每行以data:开头后面跟数据内容事件与事件之间用空行\n\n分隔。可以带id:、event:、retry:等字段分别用于标识事件序号、自定义事件类型、断线重连的时间间隔。最关键的点是事件必须被完整发送且每个字段要用空行分隔。很多人在自己写 Push 服务时容易漏掉那个空行浏览器会一直收不到事件。另外如果一条数据本身包含换行就要拆成多条data:行客户端会自动用换行符拼接。我踩过的另一个坑是SSE 的编码默认是 UTF-8一旦有中文字符被错误转码前端解出来就是乱码。在实际大模型接口中常见的 SSE 变体还有两种格式旧版允许一行输出多个 JSON 片段用换行符分隔前端需要一次性解析体验上不够“逐字”。新版标准做法是每个 Token 或一小段文本作为独立事件推送事件之间以空行隔离前端逐事件处理。这种方式对打字机效果最友好。我做流式对接时优先采用“新版标准事件流”格式每个事件携带一个增量文本块前端拿到直接拼接渲染。这个选择和具体模型服务商无关是通用约定。2.3 为什么推荐用 SSE 而不是轮询和 WebSocket很多人在选择流式方案时会犹豫轮询不行吗WebSocket 不是更强大吗我分别解释一下为什么 SSE 在大多数场景下是更优解。轮询的问题在于浪费资源和时间滞后。客户端每隔几百毫秒请求一次查“有没有新内容”相当于大炮打蚊子。如果服务器生成很快第一毫秒就产出了你也要等下个轮询周期才能拉到如果服务器生成很慢你又反复打空请求白白消耗带宽和服务连接数。最终结果是实时性差、资源开销大、还容易触发限流。WebSocket 的实时性是强但使用成本明显更高。它需要连接握手需要维护长连接状态需要处理心跳保活、断线重连、消息编解码。对于纯“服务端推→客户端收广播”的场景用 WebSocket 引入复杂度收益并没有任何提升。而且 WebSocket 的协议栈调试难度比 SSE 高不少跨网关、跨代理时更容易出问题比如某些代理对 Upgrade 头处理不当。SSE 则智能得多。它本质上是一次普通 HTTP 请求只是响应一直不结束。代理和防火墙对它友好可以直接走 CDN自带断线重连和事件 ID 机制Last-Event-ID 头回传这些特性让它在 LLM 这类单向流式场景里成了绝对主流。3. 服务端流式接口的实现与关键参数3.1 基于 FastAPI 的流式响应示例后端框架层出不穷但万变不离其宗。我这里用 FastAPI 演示一个典型的 SSE 流式接口因为它语法简洁而且自带 StreamingResponse省掉了很多手工设置。为了贴近真实场景我模拟了一个接入大模型并用流式返回的函数。核心代码如下import asyncio import json from fastapi import FastAPI from fastapi.responses import StreamingResponse app FastAPI() async def mock_llm_stream(prompt: str): # 模拟模型生成过程这里按批生产文本片段 chunks [ 你好, 很高兴, 为你服务。, 流式输出, 本质上就是, 分块传输。, ] for chunk in chunks: await asyncio.sleep(0.3) # 模拟生成耗时 yield fdata: {json.dumps({message: chunk}, ensure_asciiFalse)}\n\n app.get(/api/chat) async def chat(message: str): return StreamingResponse( mock_llm_stream(message), media_typetext/event-stream, headers{ Cache-Control: no-cache, Connection: keep-alive, X-Accel-Buffering: no, # 禁用 Nginx 缓冲 } )这里有几个关键点要展开讲。media_typetext/event-stream必须写对写错的话浏览器不识别流式格式会把它当普通文本处理。Cache-Control: no-cache是防止代理或浏览器缓存整个响应否则用户可能看不到增量内容。X-Accel-Buffering: no是给 Nginx 看的特殊响应头让 Nginx 不要缓冲响应体直接透传流式数据。这个头在直接对接公网部署时尤其重要很多人流式返回失效就是被反向代理缓冲给“攒住”了。另外不要轻易在生成器里用print输出日志因为生成器在流式运行中日志直接打到控制台可以接受但如果打到日志文件可能会影响响应流的正常交付——这在某些框架中会导致数据不 flush。调试时最好通过单独的日志接口记录或者在生成器外单独开协程做记录。3.2 哪些框架设置容易让流式“失效”同样的流式生成器换个部署环境就可能完全没有流式效果。经验上最常出问题的有三处第一是缓冲层干预。如果前面有 Nginx、Apache、GateWay 等反向代理默认开了响应缓冲它会把服务端吐出来的小块数据攒成一大块再发给客户端。用户看到的就不是逐字渐显而是等全部生成完一次性出现。解决办法有两个在服务端响应头上加X-Accel-Buffering: no适合 Nginx或者在反向代理配置里关掉当前路由的 proxy_buffering例如 Nginx 的proxy_buffering off;。第二是框架缓冲区设置。某些 Web 框架尤其是 Java 系的 Servlet 或 Spring 的老版本默认会缓冲输出流需要手动调用response.flushBuffer()或设置ResponseBody的写模式否则即使你写了yield或write内容也会积压在缓冲区迟迟不发。Python 的 WSGI 服务器如早期版本的 Gunicorn也以缓冲著称生产环境建议直接用 Uvicorn 或其他支持 ASGI 的服务器跑流式接口。第三是客户端读取方式不对。有些客户端库比如某些老版 Axios会把整个响应一次性接收要配置responseType: stream或使用支持流式读取的底层 fetch API。这个问题我放在前端章节详细讲。我实际部署时遇到过经典一幕本地开发一切正常字是一蹦一蹦出来的部署到服务器后变成等十秒整个回复“啪”一下出现。一顿排查后确认是 Nginx 配置里默认开了 proxy_buffering。给接口加了X-Accel-Buffering: no后立即恢复正常。所以这个头我对流式接口的标配。3.3 大模型服务对接的流式参数注意点如果直接对接第三方大模型服务如 OpenAI 兼容接口一般是通过它的 SDK 或 HTTP 接口开启流式模式。最常见的做法是curl -N https://api.llm.example.com/v1/chat/completions \ -H Content-Type: application/json \ -d { model: some-model, messages: [{role: user, content: 你好}], stream: true }-N表示禁用 curl 的缓冲实时打印响应内容。返回结果是一串 SSE 事件流每个事件里的choices[0].delta.content字段就是增量文本。这里有一个容易被忽略的关键点请求参数里要显式设置stream: true并且要确认模型服务商是否支持流式。很多模型平台默认stream为 false如果不传服务器会把整个生成结果攒好一次性以 JSON 返回你的前端代码就收不到增量事件。另外某些平台还要求传stream_options: {include_usage: true}来在流式响应的末尾返回 Token 用量统计方便做计费与成本分析。不是所有服务都支持但值得确认能省去后面单独查用量接口的麻烦。对于本地私有化部署的开源模型如 vLLM、TGI 之类同样会暴露兼容接口流式参数也是一样的语义。4. 前端流式消费与渲染实战4.1 用 fetch 和 ReadableStream 处理流前端对接流式接口最核心的是不能把整个响应一次性等完。现代浏览器都支持fetch返回的response.body是一个可读的流对象我们可以逐段读取。这里先给出一个基于 fetch 的完整实现看起来并不复杂但细节量巨大。async function chatStream(message, onChunk, onDone, onError) { try { // 发起普通 fetch 请求 const response await fetch(/api/chat?message encodeURIComponent(message), { method: GET, headers: { Accept: text/event-stream, }, }); // 检查响应格式是否正常 if (!response.ok) { throw new Error(HTTP response.status); } // 读取响应流 const reader response.body.getReader(); const decoder new TextDecoder(utf-8); let buffer ; while (true) { const { done, value } await reader.read(); if (done) break; // 将二进制块转为文本 buffer decoder.decode(value, { stream: true }); // 按双换行切分 SSE 事件 const events buffer.split(\n\n); buffer events.pop(); // 保留不完整事件 for (const event of events) { if (!event.trim()) continue; const lines event.split(\n); for (const line of lines) { if (line.startsWith(data:)) { const data line.slice(5).trim(); if (data [DONE]) { onDone(); return; } try { const jsonData JSON.parse(data); onChunk(jsonData.message || ); } catch (e) { console.warn(JSON 解析失败忽略该事件, data); } } } } } onDone(); } catch (error) { onError(error); } }这段代码有几个必知细节TextDecoder(utf-8)必须用流模式{ stream: true }否则碰巧把一个多字节中文字符拆成两个二进制块时会直接解出乱码。浏览器读取流时每次拿到的是一个 Uint8Array需要指定解码器才能转成字符串。buffer.split(\n\n)是按 SSE 事件分隔符切分。为什么要buffer.pop()因为最后一个事件可能只收到一半没凑齐双换行。把半个事件留在 buffer 里等下次数据到达后再拼接这个处理逻辑很多人会漏掉它直接关系到在低速网络下能否稳定解析流式消息。另外data: [DONE]是服务端约定好的结束标记。遇到它就要停止读取并调用完成回调。格式不统一的服务可能用event: done或空流结束来标识需要按你对接的服务实际情况做匹配。4.2 打字机效果与渲染策略的细节拿到增量文本后怎么渲染到页面上也很讲究。最直接的思路是每次收到一块文本就往容器元素的 textContent 里追加但如果拼的是大段 HTML要特别小心 XSS 注入。对大模型回复推荐只做纯文本渲染或者用一个转义函数处理后再插入 DOM。我常用的吞字渲染方式如下const contentDiv document.getElementById(content); const fullText []; function appendChunk(chunk) { fullText.push(chunk); const text fullText.join(); contentDiv.textContent text; // 自动滚动到底部 contentDiv.scrollTop contentDiv.scrollHeight; }为了让屏幕上看起来有“打字机”效果服务端流式推送本身就有间隔感前端不需要额外再加延迟。但如果服务端一次性推了十几个片段、间隔极短客户端会因渲染太快而失去逐字渐显的效果。这时候可以加一个小的缓冲队列控制每 30 到 50 毫秒渲染一次。这是我实测下来节奏感比较合适的区间。自动滚动这里有一个体验优化点当用户在阅读历史内容时自动滚到底部反而很烦。所以一般会在容器内加一个“是否在底部”的判断只有用户接近底部时才自动跟随。比如监听 scroll 事件判断scrollTop clientHeight 50 scrollHeight就跟随否则不跟随。这个细节对长文本尤其重要。4.3 断线重连与取消请求的完整方案流式请求是长连接一旦网络波动或服务端异常连接经常会被中断。SSE 规范里服务端可以通过事件 ID 来让客户端重连时带上 Last-Event-ID从而实现从断点续传。但在 fetch 手写流解析的模式下这个机制需要你自己实现。我的做法是在事件里带上一个序号字段比如id: 12客户端每次处理完一个事件就记录该序号。如果连接断开后重连就在请求头里加Last-Event-ID: 12服务端据此从序号 12 之后继续推送。注意这个头是 SSE 协议规范要求的很多服务端框架未必默认支持需要自己解析并跳过已发送部分。另外用户不想继续等生成时必须支持主动取消。fetch API 是支持 AbortController 的const controller new AbortController(); const signal controller.signal; async function chatStream(message, callbacks) { const response await fetch(/api/chat, { signal, /* ... */ }); // ... } // 用户点击“停止生成”按钮 stopButton.addEventListener(click, () { controller.abort(); });调abort()后fetch 会抛出一个 AbstError需要在 catch 中区分“用户主动取消”和“网络错误”不要把它当报错提示给用户。实践中点击停止按钮时 UI 应显示“已停止生成”而不是“请求失败”。一个你必然会在实际中遇到的坑用户快速连续提问时上一次未结束的流式请求如果没有取消会继续回流数据导致前端新开一轮对话时文本被前一个会话的内容污染。所以每次新请求发出前一定要 abort 掉上一个未完成的流并重置内部状态。这个处理在并发场景下极其关键。5. 流式输出全链路故障排查与避坑指南5.1 我踩过的典型问题和排查路径流式输出部署到生产环境后我遇到的故障远比开发时多。以下按频率从高到低列出几个典型问题和对应的排查方法。问题一本地正常部署后变成一次性返回这个现象前面提过主要怀疑 Nginx 或网关开启了缓冲。排查时直接用命令行测看响应是否边到边显示curl -N --no-buffer https://your-api.example.com/api/chat?message你好如果命令行也一次性打印那问题在服务端或反向代理如果命令行能流式打印但页面不流式那问题在客户端读取代码。确认后在响应头里加X-Accel-Buffering: no或者改 Nginx 的proxy_buffering off;。问题二中文乱码常见原因是返回头没有声明Content-Type: text/event-stream; charsetutf-8或网络传输分层时编码不一致。排查时先看响应头再确认生成器的编码方式。推荐在生成器内部对每个输出做 UTF-8 编码确保。前端用TextDecoder(utf-8)解码可以解决大部分乱码。问题三流式时有明显的卡顿现象服务端推一批数据过来后长时间无数据然后突然又涌来一批。这种现象通常是服务端处理逻辑本身在“等待”比如模型推理确实是分批产出但某批耗时过长也可能是反向代理的缓冲设置了较大的分段阈值。排查时建议先把服务端内部的生成耗时打点记录确认是不是模型推理自身的问题。若是模型推理的问题可以调低温度或缩短最大 token 数来降低单批生成时间。问题四前端 state 不同步很多前端框架比如 React、Vue对大数组的频繁更新处理不好流式数据一段段 push 进来会导致渲染卡顿。我实测下来把流式文本放在一个 ref 或一个独立的 mutable 对象里每次只改文本内容然后通过一个低频的渲染机制如每帧强制重绘、或 rAF 控制节流更新 UI流畅度会好很多。这是数据驱动框架里很典型的性能优化点新手很容易碰到“文本越界长就越卡”的问题。问题五连接断开后不会自动恢复SSE 规范里浏览器 EventSource 可以自动重连但手写 fetch 流没有这个特性。我在前端代码里加了一个简单的重试机制检测到异常中断时使用指数退避方式首次 1 秒最多 30 秒实现自动重连。注意每次重连前要把已展示的文本备份好服务端断点续传的逻辑若没实现至少避免内容被重复拼接。一个比较稳妥的降级做法是重连时把已展示文本作为历史发送给服务端让它生成时跳过已生成部分或者干脆重新生成整个回复简单但消耗大。从产品角度考虑多数场景下让用户手动点击“重新生成”更省事。现象优先排查点修复方式一次性返回Nginx 缓冲proxy_buffering off;或X-Accel-Buffering: no中文乱码响应头 charset设置text/event-stream; charsetutf-8流式卡顿服务端批耗时/代理分段打点分析模型生成耗时调低代理缓冲阈值侧边状态不同步前端渲染策略使用 mutable ref rAF 节流渲染断线不恢复无自动重连机制实现指数退避重连或 EventSource 原生方案5.2 生产环境的性能与并发考量流式接口比普通接口对服务器资源的占用要高一些因为每个请求都占用一个常驻连接且持续占着 I/O。如果并发量上来容易把后端的连接数打爆。一个常见误区是给所有接口都上流式。不是所有接口都需要流式只有真正耗时长、用户等待感强的才合适。像登录、简单查询这种秒回接口上流式反而是负优化增加服务器负担和前端代码复杂度。真正生产化时要注意几个指标设置合理的读超时和写超时。读超时不要太短否则模型思考超过几秒就断连写超时要大于最慢的单批产出间隔。一般建议读超时 60 秒以上写超时 30 秒以上。并发连接数有限制。Nginx 默认worker_connections和代理长连接数都要调优。如果单机量大可以考虑单独划一域名给流式接口和应用主接口隔离开这样主接口不会被流式拖垮。负载均衡无状态。流式接口后端的服务实例要注意连接亲和性问题断线重连时最好还是落到同一实例否则恢复连接拿不到之前的状态。最省事的方式是每个流式请求都是完全无状态、由客户端带回上下文这样即使换实例也没关系。LLM 场景一般通过请求消息数组携带历史来实现天然满足这个要求。另外日志要做好降噪。流式接口如果每个 chunk 都打一条日志一天的日志量会非常恐怖。建议只在开始、结束和异常时打印关键信息chunk 级别的日志只保留在 debug 模式。我见过有人生产环境开着 debug 日志结果一天几个 GB磁盘都写满了。5.3 服务端推流常见异常汇总异常码或现象原因处理方法ECONNRESET客户端断开服务端写入失败忽略该次写入异常结束生成timeout 报错读超时太短或模型无响应调大读超时加心跳包维持连接ReferenceError: buffer is not defined前端漏定义缓冲变量检查代码里 buffer 的作用域流式返回中夹杂非 SSE 文本服务端误输出普通日志把日志输出改到 stderr 或独立文件前端收到多个 data 行但无法解析使用了非标准格式统一改标准事件流或自定义解析器这里特别提醒一点SSE 标准里一个事件可以分多行 data如果业务数据本身是 JSONJSON 里不能有裸换行否则会把事件拆得乱七八糟。最好的做法是将 JSON 序列化后的字符串作为单行data:推送如果太长需要换行必须在发送前把换行转义前端再做反转义。我们通常直接把 JSON 压成一行不换行最省事。6. 体验打磨与进阶思路6.1 打字机效果的节奏控制技巧流式输出实现出来后还有个体验进阶问题显示太快也未必好。如果服务端很快把一整个段落都推完了用户的视觉体验和一次性加载完没有区别中间等待被压缩了但“看到生成过程”这种安心感也消失了。我在实践中摸索出来的经验用户最理想的节奏是“以正常阅读速度略快一点的速度逐字出现”。如果服务端本身速度偏快可以在前端加一个简易节流函数比如保证每 40 毫秒最多渲染一个字符或一个片段。这样用户不会因为文字闪现而感到突兀。但如果反过来服务端生成极慢比如每 5 秒一个 chunk在前端做“假打字机”反而加重焦虑。这种情况更合理的做法是显示一个进度指示器比如“正在生成第 2/5 段”这类进度提示或者一个简洁的呼吸指示条让用户知道系统没有挂掉。纯文本 UI 也可以用“打点动画”生成中加入一个滚动的省略号来缓解等待焦虑。6.2 停止生成与重新生成的配合停止生成功能是流式对话的必需品。用户在大模型回复了一段不想要的内容后一般会想立即叫停。我在实现时加入了一个比较完善的交互逻辑点击“停止生成”按钮前端调用 abort并把当前已生成内容保留在界面里。同时将“完整生成结果”标记为未完成状态此时用户不能对这段内容做“复制完整全文”等操作但可以重新提问。如果“重新生成”被触发前端清空当前内容重新发起流式请求而停止按钮保持可用直到完成。这里有一个细节停止后已生成的内容是否保留取决于产品定位。如果对话是逐轮式的保留已生成内容可以防止误删如果内容质量太差干脆清空重来更干净。我一般选择保留并显示一句“已停止生成可点击重新生成”提示。这样既能保留上下文也给了用户再次尝试的出口。6.3 低成本接入流式输出的降级方案如果你的现网后端暂时不好大改还有一个紧急的降级方案用轮询伪装流式。服务端每 500ms 或 1 秒把“当前生成进度快照”通过普通接口返回给前端前端拿到快照后替换展示。这个方案虽然不优雅但能让用户体验快速得到改善特别适合那种老项目接口没法立刻重构的场景。快照接口的数据结构可以设计的很简单{ status: generating, content: 当前已生成的内容快照, finished: false, updatedAt: 1720000000 }前端拿到新的快照后如果内容比上一轮长就把新内容渲染出来如果 status 变为 finished就结束轮询切换为完整结果态。这个方案的缺点是服务端每轮都要序列化整个内容快照内容很长时带宽开销不小优点是改造面小前端代码基本不用动。当然这只是过渡方案。有条件还是建议直接上 SSE 或真正的流式接口长期来看成本和体验都会更好。但如果项目排期紧、改动面大先用轮询把最核心的“渐进显示”效果做出来是完全可以接受的产品决策。上线之后有空档期时再逐步切换到真正的流式方案产品体验还会有一次跃升。流式输出不是哪个框架的专属能力而是一种服务端与客户端协作模式的思维转变。它把“等待”变成了“过程”把黑盒变成了白盒。按照我自己在多个项目里落地的经验最稳妥的路径就是先把服务端流式接口打通再用前端 fetch ReadableStream 做精细消费最后再加上断线恢复、停止生成、节奏控制这些体验细节。所有坑都踩过一遍之后再看流式输出这件事本质就是理解传输层的缓冲机制、掌握事件协议格式、以及做好核心的边界处理。希望这篇实战记录能帮你少走几步弯路让你用户第一次看到“逐字蹦出来的回复”时也会觉得你写的东西很高级。