流式输出怎么实现？SSE 和 WebSocket 怎么选？

流式输出用的是 SSE（Server-Sent Events）。服务端不是一次性返回完整响应，而是保持连接、按帧把生成的内容推给客户端，前端收到一帧就渲染一帧，用户体验上就是字一个个出来。

SSE 和 WebSocket 的区别主要是：SSE 是单向的（只有服务端往客户端推），基于普通 HTTP，实现简单，浏览器有原生的 EventSource 支持，还能自动重连；WebSocket 是双向的，需要协议升级，适合聊天室、协同编辑这类两端都要主动发消息的场景。

大模型 API 用 SSE 是因为场景本身就是单向的——客户端发一次请求，服务端持续返回，中途不需要客户端再说话。所以 SSE 够用，而且比 WebSocket 简单。

为什么只有 60 分：结论全对，但完全停在"教科书对比"层面。没有任何具体的事件名、没有任何一个坑、也没提流式带来的连带后果。这样的回答面试官无法区分你是用过还是看过。

先纠正一个常见误解：SSE 不是和 WebSocket 并列的协议，它就是一次普通的 HTTP 响应，只不过响应体是长连接、按 event: / data: 这套帧格式一帧一帧发，空行结束一帧。理解这一点之后，后面所有的坑都能推出来。

协议上三家是一致的，语义上完全不兼容。 截至 2026-08，OpenAI、Anthropic、Gemini 的文本推理流式全部是 SSE over HTTP POST，没有一家用 WebSocket。但事件语义各不相同：Anthropic 是块级状态机（message_start / content_block_delta / message_stop，没有 [DONE] 哨兵），OpenAI Chat Completions 是 delta 增量加 data: [DONE]，而 Responses 和 Gemini 的新接口是语义事件流。所以"换个 base_url 就能切模型"在流式场景是假的，网关必须写一层事件翻译。

选型判据我只用一条：只有满足"真双向、二进制音视频、单连接多路复用"任一条时，才值得上 WebSocket。 文本推理三条都不满足，所以三家都没用它。WebSocket 的代价也很清楚——连接是有状态的，绑死在单个实例上，滚动发布会踢掉活跃会话；而 SSE 每次是无状态 HTTP，重连即可换实例。

实践里我踩过几个坑，都挺典型：

• 浏览器原生的 EventSource 不能设请求头，构造器只接受 URL 和一个 withCredentials，所以带 Authorization 的 API 永远不能用它直连。实际做法是 fetch 加 ReadableStream 自己解帧。代价是规范白送的自动重连、断点续传、退避策略全都要自己重写一遍，这一点很多人换的时候没意识到。
• 代理缓冲是最经典的一个。nginx 的 proxy_buffering 默认是开的，会把上游响应先攒起来再下发——表现就是"本地好好的，上线后转圈几秒再整段砸出来"。上游可以发 X-Accel-Buffering: no 来关，但这个头可能被网关的 proxy_ignore_headers 吃掉。
• 空闲超时。proxy_read_timeout 默认 60 秒，模型长时间思考不吐字就会被切。规范给的解法很明确：每 15 秒左右发一个注释行当心跳。

因为踩过这些，我们把 TTFT 拆成了两个指标：Pipeline TTFT（第一个字节到达客户端）用于对外 SLO，Model TTFT（推理返回第一个 delta）用于隔离模型本身。两者背离时，问题一定在非模型环节——网关缓冲、检索、上下文拼装、鉴权。这个拆分让我们后来的排查快了很多。

最后是流式的连带后果，我觉得这才是这道题的真正深度：流式会同时让三件事降级——限流精度（流式下输入输出 token 都只能估算）、响应侧护栏（无法对每个 token 去查一次外部系统，只能"先出后审"）、工具入参的结构化输出（API 不缓冲不校验，可能收到半截的非法 JSON，max_tokens 截断还会把参数切一半）。所以上流式不是"加个参数"，是要接受这三笔账。