AI流式传输选型实录，SSE与WebSocket的边界在哪，生产环境如何避坑

某AI客服系统全量上线第三天，运维紧急介入：问答接口QPS莫名翻倍，前端大量用户反馈‘回答半天不吐字’，反复点击重试导致流量雪崩。排查发现，问题不在大模型推理，而在传输层——Nginx默认开启proxy_buffering，将流式响应攒批发送，首字延迟高达8秒；前端使用裸EventSource，断连无提示、慢速无反馈，用户只能靠狂点续命。这并非孤例，而是流式AI服务落地时普遍遭遇的‘管子爆裂’现象。

SSE与WebSocket的本质差异，决定其适用边界

Server-Sent Events（SSE）是单向、基于HTTP的长连接协议，专为服务端向客户端持续推送数据设计；WebSocket则是全双工、独立于HTTP的持久化通道，支持双向实时通信。二者在AI流式输出场景中的分野极为清晰：

SSE适用场景：下行主导、低频交互、对延迟容忍度相对较高。典型如单轮问答、摘要生成、代码补全等——用户发出请求后，只需接收模型逐步输出的token流，无需频繁上行交互。
WebSocket适用场景：双向实时、高频上行、需服务端主动推且客户端也需频繁响应。典型如多轮协作编辑、语音对讲、实时游戏状态同步、或需要客户端动态调整生成策略的智能体交互。

关键判据在于“上行频率”与“连接生命周期”。若用户一次提问后仅被动接收结果，连接在回答结束即可关闭，SSE成本更低、部署更轻量；若对话中需多次中断、追问、修正指令，则WebSocket的全双工能力不可替代。

裸EventSource的四大生产陷阱

许多团队初期选择EventSource，因其API简洁——一行new EventSource即可启动流式接收。但该方案在生产环境中暴露严重缺陷：

鉴权受限：仅支持GET请求，无法携带自定义Header。Token只能拼入URL，导致网关日志、CDN缓存、浏览器历史中明文暴露，安全评审直接驳回。

断线重连失效：虽支持自动重连，但若服务端未配合返回Last-Event-ID，重连后要么丢消息，要么从头重发，用户体验断裂。

代理缓冲干扰：Nginx默认启用proxy_buffering on，流式响应被攒批发送，首字延迟完全失控，与AI低延迟预期背道而驰。

超时机制缺失：无内置心跳保活，长时间空闲连接易被中间代理（如负载均衡器）静默断开，前端无感知。

生产级SSE客户端必须解决四件事

真正可用的SSE实现，需绕过原生EventSource限制，转向fetch + ReadableStream方案，同时满足：

支持POST请求与自定义Header（如Authorization: Bearer xxx），规避URL明文风险；
可接受lastEventId参数，服务端按ID续传，避免重复或丢失；
实现指数退避重试策略，结合AbortSignal支持手动取消；
解析SSE标准格式（id/event/data），兼容服务端返回的结构化事件。

参考实现中，核心逻辑包括：通过fetch发起流式请求，读取ReadableStream的reader循环调用read()，按\n\n分割块并解析每段SSE消息；重连时携带上次收到的Last-Event-ID；错误时触发退避算法（如baseDelayMs × 2^n），避免瞬时洪峰。

WebSocket的隐性成本常被低估

连接资源开销：每个WebSocket连接需网关维持状态，连接数直接关联实例成本。对于低频使用的客服页（用户问完即关），为单次对话维持全双工长连接，资源利用率极低。
移动端脆弱性：设备切后台、锁屏、进入电梯等场景极易断连，需自行实现完整重连链路：重鉴权 → 重订阅 → 消息回放 → 心跳保活。标准WebSocket API不提供这些能力。
协议复杂度上升：需定义自定义消息格式（如{type: 'ping', seq: 1}）、处理乱序、应对服务端主动关闭等异常流。

实际选型决策树

可按以下流程快速判断：

是否存在高频上行交互？（如用户中途插入“等等，换种说法”）→ 是 → WebSocket；否 → 进入2。

是否要求严格低延迟（首字<1s）且部署环境可控？→ 是 → 优化SSE（禁用proxy_buffering、用fetch+stream）；否 → 原生EventSource可短期过渡。

是否需跨域或受同源策略限制？→ SSE天然支持CORS，WebSocket需服务端显式配置Access-Control-Allow-Origin。

是否需复用现有HTTP基础设施？→ SSE复用HTTP/2多路复用与TLS，运维友好；WebSocket需额外配置连接池与健康检查。

值得注意的是，HTTP/2 Server Push已逐渐被弃用; 而新兴的gRPC-Web虽支持流式，但前端生态成熟度仍不及SSE。因此在2026年主流技术栈中，SSE仍是AI流式输出的首选方案，前提是完成生产加固。

行业趋势：入口迁移倒逼传输层升级

这一技术选型问题正随AI应用形态演变而凸显。以Salesforce的AIforce为例，其将CRM能力开放至Slack、Claude等第三方AI界面，用户不再进入传统网页操作，而是通过聊天框触发数据查询与流程执行。此类场景下，前端需在轻量会话中稳定接收多轮流式响应，同时可能穿插用户指令修正——这恰好处于SSE与WebSocket的模糊地带。

解决方案往往采用混合架构：初始请求用SSE获取主回答流，当检测到用户中断或追问时，动态升级为WebSocket通道处理后续交互。Spring AI 2.0框架亦支持此类模式，其Advisor链可在运行时根据上下文切换传输策略。

归根结底，传输协议不是技术偏好问题，而是业务模式的镜像。当AI从“生成内容”走向“执行任务”，连接的稳定性、可控性与成本效率，将比模型参数量更早成为系统瓶颈。一线工程师需跳出“能跑就行”的惯性，从连接生命周期、错误恢复路径与基础设施约束三方面重新评估SSE与WebSocket的真实边界。