单向流式输出场景下应选SSE：它基于HTTP、单向推送、自动重连、实现简单、部署成本低、兼容性好，而WebSocket双向能力闲置却需额外处理握手、心跳、重连及网关穿透等问题。
大模型单向输出场景下，SSE 通常比 WebSocket 更具性价比——核心在于“够用、省事、少踩坑”。不需要双向通信时，硬上 WebSocket 就像用液压千斤顶拧螺丝：能动，但费力、占地方、还容易滑丝。
看通信方向是否真需要双向
AI对话流式返回（如逐 token 输出）、推理任务进度推送、日志实时展示等，客户端只发一次请求，后续全是服务端推数据。这种纯单向流，SSE 天然匹配；WebSocket 的双向能力完全闲置，反而要额外处理握手、心跳、重连、连接池管理等冗余逻辑。
- 客户端只需
new EventSource('/api/chat/stream')，几行代码开连 - 服务端用
SseEmitter（Java）、text/event-stream响应头（Go/Node）即可分块写入 - WebSocket 则需维护连接状态、定义消息协议、防断线、做 ping/pong 检测
算部署与运维的实际成本
SSE 走标准 HTTP 长连接，复用现有 Nginx、CDN、负载均衡器和 TLS 终止设施，几乎零配置适配；WebSocket 需穿透代理层，常因超时、升级头被过滤、不支持 ws 协议等问题卡在网关环节。
大模型Token成本节约
下载
大模型 Token 成本节约工具。在请求到达大模型之前自动压缩 prompt 和上下文，减少 60-95% 的 token 消耗，直接降低 API 成本。支持 Claude/OpenAI/Gemini 等主流模型，提供代理模式、CLI 包装、Python SDK 和 MCP Server 四种接入方式。内置一键安...
- Nginx 默认支持 SSE，只需配
proxy_buffering off和proxy_cache off - WebSocket 要显式开启
Upgrade和Connection头透传，否则握手失败 - 云厂商 WAF 或 API 网关可能默认拦截非 GET/POST 请求，SSE 不受影响，WebSocket 易被误杀
看客户端体验与容错能力
SSE 浏览器原生支持自动重连，断开后默认 3 秒重试，可自定义 retry: 5000；WebSocket 断线即断，必须手动实现重连+会话恢复逻辑，否则用户看到“连接已断开”就卡住。
- 流结束时，SSE 自然关闭连接，前端
onclose可明确区分“完成”和“异常” - WebSocket 关闭事件无上下文，容易把正常结束误判为故障，导致重复请求或 UI 错乱
- 移动端弱网下，SSE 的 HTTP 底层更稳定，WebSocket 更易触发 TCP 重传或 RST
别被“二进制”或“低延迟”误导
大模型文本流本质是 UTF-8 字符串，token 级别推送对带宽和延迟要求不高。SSE 的文本限制不是瓶颈；所谓 WebSocket “更低延迟”，在百毫秒级的 AI 生成场景中几乎不可感知，但其连接建立耗时（HTTP 握手 + 协议升级）反而可能比 SSE 的纯 GET 请求更长。
- Base64 编码二进制？大模型输出不需要
- 首字节时间（TTFB）：SSE 与普通 HTTP 接近；WebSocket 多一次 round-trip 升级
- 真实瓶颈在模型推理速度，不在传输协议
