eventsource适用于仅需服务器单向推送的场景，如ai流式输出、日志刷新、订单通知；它基于http、自动重连、无需协议升级，但仅支持utf-8文本且不兼容ie。
只用服务端推数据，EventSource 就够了
如果你的场景是“服务器发、浏览器收”，比如 AI 对话流式输出、日志实时刷新、订单状态通知，EventSource 是最直接的选择。它基于标准 HTTP，不需要协议升级，服务端只需返回 Content-Type: text/event-stream，客户端几行 JS 就能监听：eventSource.onmessage 或 eventSource.addEventListener("message", ...)。浏览器自动处理断线重连（默认 3 秒后重试），你不用写心跳逻辑、不操心连接状态管理。
常见错误是服务端忘了设响应头，或用了 res.end() 提前关闭连接；还有人误以为 EventSource 能发消息给服务端——它不能，要发就得另起一个 fetch 或 XMLHttpRequest。
WebSocket 连接建立失败，大概率卡在握手阶段
WebSocket 不是 HTTP 请求，而是先发一个带 Upgrade: websocket 的 HTTP 握手请求，成功后才切换协议。很多线上问题出在反向代理（如 Nginx）没透传升级头，或 WAF 拦截了非标准方法。典型错误现象是前端报 WebSocket connection to 'wss://...' failed，但服务端日志无记录——这时要检查代理配置是否包含：proxy_http_version 1.1、proxy_set_header Upgrade $http_upgrade、proxy_set_header Connection "upgrade"。
另一个易忽略点：WebSocket 不支持跨域时的凭据（withCredentials），而 SSE 可以正常携带 Cookie。如果鉴权依赖 session，SSE 更省事。
传输二进制或需要低延迟双向交互，必须选 WebSocket
比如音视频帧转发、协同编辑光标同步、实时游戏指令，这些场景要求客户端和服务端都能随时发、延迟敏感、且数据可能是 ArrayBuffer。SSE 只支持 UTF-8 文本，二进制得 Base64 编码再解码，性能损耗明显；而 WebSocket 原生支持 send(ArrayBuffer) 和 binaryType = "arraybuffer"。
但代价是复杂度陡增：你要自己实现心跳（ping/pong）、连接恢复（重连 + 断线期间消息暂存）、消息序列化（比如用 Protocol Buffers 压缩 payload）。SSE 没这些事——它就是一条单向文本流水线。
兼容性不是唯一指标，部署链路才是关键瓶颈
SSE 在 Safari 16.4+ 才完全支持 EventSource 的 onerror 细粒度控制，旧版 Safari 需要 polyfill；但 WebSocket 在 IE10+ 就稳定可用。不过真实项目里，更常卡在运维侧：CDN 是否缓存 text/event-stream？负载均衡器是否支持长连接保活？Nginx 默认 proxy_read_timeout 是 60 秒，SSE 必须调大，否则连接被静默断开。
WebSocket 则面临另一类问题：连接数暴涨时，服务端需维护大量活跃 socket，内存和文件描述符压力大；而 SSE 复用 HTTP 连接池和现有中间件，更容易水平扩展。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
