大模型应用里 WebSocket 和 SSE 怎么选？各自的局限是什么？

先这样答

先看通信模式的需求。大模型逐 token 流式输出是「服务器单向推」，SSE 就够了：它基于 HTTP 长连接，服务器向客户端推事件流，实现简单，浏览器原生支持，自带断线重连。请求响应模型不用改，客户端只发一次请求，后续都是推送，这是主流大模型应用选 SSE 的原因。

WebSocket 是全双工长连接，双向都能主动发消息，适合协作编辑、实时对话连语音这种双方高频互发的场景。代价是连接状态要自己管理：心跳保活、断线重连策略、网关超时配置，都比 SSE 麻烦。

各自的局限要主动说：SSE 只能服务器到客户端，客户端要发新消息得另起请求；老浏览器和部分代理对 HTTP/1.1 下的连接数有限制。WebSocket 过代理和企业防火墙容易被掐断，且没有 SSE 那种原生的重连语义。选型判断一句话：单向推流用 SSE，真双向实时才上 WebSocket，别为了技术新潮给流式输出硬上全双工。

面试官会怎么追问

• 「语音对话场景为什么经常还是 WebSocket？」 语音流是客户端持续上传音频、服务端持续下发识别和合成结果，双向都是高频流，SSE 的单向模型罩不住。
• 「SSE 断线重连后丢掉的中间数据怎么办？」 SSE 可以带事件 id，重连后从上次位置续传；应用层也要设计幂等，客户端能容忍从最近的完整消息重新开始。
• 「HTTP/2 之后 SSE 的连接数限制还存在吗？」 基本解除，HTTP/2 多路复用让多个 SSE 流共享一条连接，但要注意代理和服务端对流的超时配置。

回答的坑

说「WebSocket 更先进所以一律用它」，暴露没有按通信模式选型的意识。

漏掉 SSE 只能单向这个根本局限，被追问「客户端怎么发消息」时接不住。