EventSource vs WebSocket vs Fetch Stream：前端实时通信方案全对比

一、前言

前端实时通信有三种主流方案：

方案	协议	方向	复杂度
SSE (EventSource)	HTTP/1.1	服务端→前端	⭐
WebSocket	ws/wss	双向	⭐⭐
Fetch + ReadableStream	HTTP/2	服务端→前端	⭐⭐⭐

选错方案轻则浪费资源，重则功能不可用。本文帮你彻底搞清楚。

---

二、SSE：AI 流式输出的最佳拍档

优点

1. 零依赖原生支持：浏览器自带 EventSource
2. 自动重连：断网恢复后自动续接，无需写一行重连代码
3. HTTP 生态亲和：经过所有 HTTP 中间件（Nginx、CDN、认证）
4. 文本格式：天然适合 LLM token 流

缺点

1. 单向通信：只能服务端推送，客户端要发消息得另开请求
2. 不支持自定义 Header：无法带 Authorization，只能用 cookie
3. 连接数限制：同域名最多 6 个 SSE 连接（HTTP/1.1）

适用场景

• AI 对话流式输出
• 系统通知推送
• 实时日志流
• 股票行情推送
• 下载进度显示

---

三、WebSocket：全双工通信利器

优点

1. 全双工：客户端和服务端随时互相发消息
2. 低延迟：建立连接后无需 HTTP 握手开销
3. 二进制支持：可传 ArrayBuffer/Blob
4. 无同源限制：可连任意 ws 服务器

缺点

1. 需手动重连：断线后要自己写重连逻辑
2. 不经过 HTTP 中间件：认证、日志需自己实现
3. 连接保活：需要心跳机制防止空闲断开
4. 代理兼容性差：部分企业代理会阻断 ws

适用场景

• 即时聊天（IM）
• 协同编辑
• 多人在线游戏
• 实时数据大屏

---

四、Fetch + ReadableStream：新时代的流式方案

优点

1. POST 请求：可携带复杂请求体（对话历史、配置参数）
2. 自定义 Header：轻松带 Token 鉴权
3. 精确流控制：暂停、取消、限流随心所欲
4. HTTP/2 多路复用：一个连接承载多个流
5. TransformStream 管道：构建复杂数据转换链路

缺点

1. 实现较复杂：需要手动处理 SSE 格式解析
2. 无自动重连：重连逻辑完全自理
3. 学习成本高：Stream API 概念较多

适用场景

• AI 流式对话（首选方案）
• 大文件下载进度
• 视频流播放

---

五、决策框架：一张表搞定

你的应用需要双向通信吗？
├── 是 → 用 WebSocket
│   ├── 需要经过企业代理？ → 准备 HTTP fallback
│   └── 不需要 → ws 直连
│
└── 否 → 服务端推送数据
    ├── 需要自定义请求头 / POST 数据？
    │   └── 是 → Fetch + ReadableStream (TransformStream)
    │
    └── 不需要 → SSE (EventSource)
        └── 这就是 AI 流式打字机的标准答案

---

六、实际项目中的组合拳

真实项目往往不是只选一种，而是组合使用：

用户发送消息 → Fetch POST (携带对话历史)
AI 逐字回复   → Fetch ReadableStream (流式接收)
系统通知冰   → SSE (后台推送)
管理员实时看板 → WebSocket (双向)

---

七、面试速记

Q：AI 打字机用什么技术？

A：优先 fetch + TransformStream，因为：
- 支持 POST 携带完整上下文
- 可自定义 Authorization Header
- 精确流控制（暂停、取消）
- 流式管道：ReadableStream → TextDecoderStream → TransformStream → 渲染

Q：SSE 和 WebSocket 怎么选？

A：单向下推选 SSE（简单 + 自动重连），双向通信选 WebSocket（低延迟 + 全双工）。

---

八、总结

三种方案不是互斥的，而是各有主战场：

• SSE：AI 打字机、通知推送，简单可靠
• WebSocket：聊天、游戏、协同，低延迟双向
• Fetch Stream：AI 流式对话首选，灵活强大

掌握了这张选型地图，任何实时通信需求都能对号入座。