选sse还是websocket取决于通信方向：单向推送用eventsource，双向交互必须用websocket；前者轻量但仅服务端推，后者支持全双工且兼容性更优。
选 SSE 还是 WebSocket，关键看通信方向是否需要客户端主动发消息——如果只收不发，EventSource 足够轻量；一旦要双向交互，必须用 WebSocket。
通信方向决定技术选型
SSE 是单向通道：服务器能推数据，但客户端不能通过它发任何消息。想提交操作（比如点赞、输入内容），还得额外配一个 fetch 或 XMLHttpRequest 请求。WebSocket 则天然支持 ws.send() 和 ws.onmessage 同时工作，不用拼凑两套机制。
- 只做监控面板、行情刷新、日志流 → 用
EventSource更干净 - 聊天、协作编辑、实时表单校验 → 必须上
WebSocket - 误以为 SSE 可以“发指令”是常见误解，浏览器会静默忽略
eventSource.send()（该方法根本不存在）
连接行为与重连逻辑差异大
EventSource 的重连是自动的、可配置的；WebSocket 断开后默认不重连，得自己写逻辑。
-
EventSource收到服务器返回retry: 3000字段后，会在 3 秒后自动重试 -
WebSocket触发onclose后，连接就彻底断了，不调new WebSocket(url)就不会再连 - 手动实现 WebSocket 重连时，要注意避免雪崩重试（比如指数退避 + 最大重试次数）
- 某些代理或 CDN 会悄悄关闭空闲 HTTP 长连接（SSE 依赖的底层机制），导致比预期更频繁的重连
数据格式和传输效率实际影响开发体验
SSE 强制文本、按行解析；WebSocket 原生支持二进制，且无协议头膨胀。
- SSE 每条消息必须是 UTF-8 文本，且格式固定：
data: {...}\n\n，多字段需手动拼接event:、id:、retry: - WebSocket 发送
JSON.stringify(obj)或ArrayBuffer都直接走帧，没有编码/解码包袱 - 想在 SSE 里传图片？只能 Base64 编码再塞进
data:，体积膨胀约 33%，延迟也更高 - 服务端用 Node.js 的
express接 SSE，记得设res.flush()或res.write()，否则数据会缓存不推送
兼容性与部署成本常被低估
看似都“现代浏览器支持”，但真实环境里，SSE 在老旧代理、企业防火墙、CDN 缓存策略下更容易被拦截或截断；WebSocket 虽然握手阶段走 HTTP，但后续流量已脱离 HTTP，反而更“透明”。
- IE 完全不支持
EventSource（哪怕 IE11），而WebSocket从 IE10 就可用 - Nginx 默认会缓冲响应体，SSE 需显式配置
proxy_buffering off;和chunked_transfer_encoding on; - Cloudflare 免费版默认关闭 SSE 支持，需升级或改用 WebSocket
- 某些 iOS WebView（尤其旧版）对 SSE 的自动重连行为不稳定，
EventSource实例可能卡在CONNECTING状态不报错
真正容易踩坑的地方不在 API 写法，而在网络中间件和边缘节点对“长 HTTP 连接”的处理逻辑——SSE 表面简单，实则更依赖基础设施配合；WebSocket 看似复杂，但协议边界清晰，反而更可控。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
