选sse还是websocket关键看通信方向：单向推送（如通知、日志）用sse更轻量省心，双向交互（如聊天、协同编辑）必须用websocket；sse基于http自动重连、兼容性强，websocket需手动管理连接、支持二进制和低延迟。
选 WebSocket 还是 SSE，关键看通信方向是否需要双向。如果只是服务器往前端推数据，比如通知、日志、行情更新，SSE 更轻量省心；一旦客户端要发消息——哪怕只是点个“已读”、发条弹幕、或心跳保活——就必须用 WebSocket。
通信方向决定技术选型
SSE 本质是 HTTP 长连接，只支持服务端 → 客户端单向推送。浏览器的 EventSource 接口压根没有 send() 方法，调用会直接报错：TypeError: eventSource.send is not a function。想回传用户操作，只能额外配一个 fetch 或 axios 请求，两套连接逻辑并存，状态难统一。
WebSocket 是独立协议，握手升级后建立全双工通道，双方随时互发文本或二进制数据，适合聊天、协同编辑、实时游戏等交互密集场景。
连接维护成本差异明显
SSE 浏览器自动重连，断开后按 retry 字段间隔尝试恢复，还自带 Last-Event-ID 断点续传能力；服务端只需定期发空注释 : \n\n 或心跳事件，就能防止代理（如 Nginx 默认 60s、Cloudflare 默认 100s）主动断连。
WebSocket 没有内置重连机制：连接关闭后实例就失效，onclose 触发后必须手动 new WebSocket(url)。推荐用指数退避策略（如 1s→2s→4s→8s），并设最大重试次数（例如 5 次），避免雪崩式重连打挂服务端。
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
协议与部署兼容性需实测
SSE 复用 HTTP/HTTPS 端口（80/443），天然穿透大多数防火墙、CDN 和反向代理，但要注意 Safari 15.4+ 才支持 withCredentials，老版本跨域带 Cookie 会失败。
WebSocket 使用 ws:// 或 wss:// 协议，企业内网常禁用该协议，导致连接被拦截；虽协议本身不走 CORS，但服务端需校验 Origin 并正确返回 Sec-WebSocket-Accept 头。
数据类型和传输效率各有所长
SSE 只支持 UTF-8 文本，格式固定（event:、data:、id: 等字段），解析简单，HTTP 压缩（gzip）可用，但每次响应携带完整 HTTP 头，开销略高。
WebSocket 支持文本和二进制，帧头仅 2 字节，无 HTTP 头冗余，延迟更低；可自定义序列化协议（JSON、Protobuf），也支持 PerMessage-Deflate 压缩，但服务端需实现帧解析逻辑，开发成本更高。
