SSE在单向推送时服务器资源占用更低，因其复用标准HTTP连接、无需维护协议状态，仅需text/event-stream响应流；而WebSocket需独立socket句柄、心跳逻辑及额外连接管理，内存与goroutine开销显著更高。
单向推送场景下，SSE 通常比 WebSocket 更轻量、更稳定；但若需客户端主动发消息或低延迟双向交互，WebSocket 不可替代。
为什么 SSE 在纯推送时服务器资源占用更低
SSE 复用标准 HTTP 连接，不额外维护协议状态，每个连接仅需一个 text/event-stream 响应流。Nginx/Apache 等反向代理默认支持长连接复用，无需特殊配置；而 WebSocket 连接建立后脱离 HTTP 生命周期，服务器需为每个连接维持独立的 socket 句柄和心跳逻辑。
- Node.js 中，1000 个 SSE 连接约占用 100–200 MB 内存；同等数量的 WebSocket 连接常达 300–500 MB（含连接管理、缓冲区、超时控制）
- Go 的
net/http服务跑 SSE 时，goroutine 数量基本与并发连接数一致；而gorilla/websocket需额外 goroutine 处理读/写/心跳，资源开销翻倍 - 某些云厂商（如 AWS ALB）对 WebSocket 连接有显式并发数限制（如每实例 10 万），但对 HTTP 长连接无硬性上限
EventSource 自动重连 vs WebSocket 手动重连的实际影响
EventSource 在连接断开后会默认等待 3 秒重试，且重试间隔呈指数退避（最大约 60 秒），整个过程完全由浏览器控制；WebSocket 没有内置机制，必须手动监听 onclose、设置定时器、管理重连次数和退避策略。
- 未处理重连的 WebSocket 客户端，在网络抖动后可能永远卡在
CLOSED状态，用户看不到任何更新 - 手动实现重连时，容易忽略
onerror和onmessage之间的竞态——比如重连成功前收到旧连接残留的message，导致数据错乱 - SSE 的重连是“无感”的：只要响应头含
Cache-Control: no-cache和Connection: keep-alive，浏览器就自动续上上次的Last-Event-ID（如果服务端支持）
延迟差异在真实业务中是否明显
在多数后台任务推送场景（如模型训练进度、日志流、状态轮询替代），SSE 的端到端延迟（50–200ms）和 WebSocket（10–50ms）感知差异极小；真正拉大差距的是实现成本和稳定性。
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- HTTP/2 下 SSE 可利用多路复用，多个事件流共享同一 TCP 连接，实际吞吐并不输 WebSocket
- WebSocket 的低延迟优势只在毫秒级交互（如游戏帧同步、高频报价）中体现；一旦加了业务层序列化/鉴权/路由逻辑，两者瓶颈都落在应用代码，而非协议本身
- 实测发现：当后端使用 Python FastAPI + Uvicorn 输出 SSE 时，95% 请求延迟
80ms；同环境用websockets库，95% 延迟45ms——但前者开发耗时 1 小时，后者调试连接异常花了 3 天
什么时候该强行切到 WebSocket
不是“SSE 不够快就换”，而是“功能缺失无法绕过”时才切换。典型信号包括：
- 前端需要实时提交中间结果（如大文件分片校验、对话流中断指令），SSE 无法接收客户端数据
- 服务端需按用户行为动态调整推送频率（如用户滚动日志时暂停推送），仅靠 SSE 的
close()不足以精准控制 - 已有 WebSocket 基础设施（如统一网关、鉴权中间件、消息广播层），重复建 SSE 接口反而增加运维负担
真正容易被忽略的点是：SSE 流结束（HTTP status 200 + body EOF）在前端会被 EventSource 当作正常关闭并触发 onerror ——很多开发者误以为是断连，立刻重连，结果把“任务完成”当成“推送失败”。这比性能问题更常引发线上误告警。
