SSE vs WebSocket 核心区别
| 特性 | SSE (Server-Sent Events) | WebSocket |
|---|---|---|
| 通信方向 | 单向：服务器 → 客户端 | 双向：客户端 ↔ 服务器 |
| 协议基础 | HTTP/1.1 或 HTTP/2 | 独立的 WebSocket 协议 (ws:// / wss://) |
| 连接建立 | 普通 HTTP 请求，自动处理 | 需要 HTTP Upgrade 握手 |
| 实时性 | 较好（秒级延迟） | 极佳（毫秒级延迟） |
| 自动重连 | ✅ 浏览器原生支持 | ❌ 需手动实现 |
| 二进制支持 | ❌ 仅文本 | ✅ 文本 + 二进制 |
| 浏览器兼容性 | 现代浏览器良好 | 几乎所有浏览器 |
| 穿透防火墙 | 容易（标准 HTTP 端口） | 可能需要特殊配置 |
| 服务器复杂度 | 低 | 较高（需维护连接状态） |
适用场景对比
🟢 适合使用 SSE 的场景
| 场景 | 原因 | 典型应用 |
|---|---|---|
| AI 大模型流式输出 | 单向推送文本，无需客户端频繁发送数据 | ChatGPT、Kimi、豆包文本生成 |
| 实时通知/消息推送 | 服务器主动推送，客户端被动接收 | 新邮件提醒、系统公告 |
| 股票行情/数据更新 | 高频单向数据流，自动重连很重要 | 股票报价、仪表盘数据 |
| 日志流式输出 | 持续推送文本日志 | CI/CD 构建日志、服务器日志 |
| 新闻/社交媒体 feed | 服务器推送新内容 | Twitter/X 时间线更新 |
| 进度条/状态更新 | 服务端任务进度推送 | 文件上传进度、长时间任务状态 |
核心特征：数据主要从服务器流向客户端，客户端不需要频繁向服务器发送数据。
🔵 适合使用 WebSocket 的场景
| 场景 | 原因 | 典型应用 |
|---|---|---|
| 实时语音交互 | 双向音频流，低延迟要求 | 豆包语音合成/识别、实时语音助手 |
| 在线游戏 | 双向高频数据交换，毫秒级延迟 | 多人对战游戏、游戏状态同步 |
| 实时协作编辑 | 双向同步，冲突处理 | Google Docs、Notion 多人协作 |
| 即时通讯/聊天室 | 双向消息传递，高并发 | 微信、Slack、Discord |
| 实时白板/绘图 | 双向操作同步 | Figma、Excalidraw 协作 |
| 物联网设备控制 | 双向指令下发与状态上报 | 智能家居控制、工业设备监控 |
| 视频会议/直播互动 | 音视频双向传输 | Zoom、腾讯会议 |
| 金融交易/高频交易 | 超低延迟，双向确认 | 股票交易系统、加密货币交易 |
核心特征 ：需要客户端和服务器之间频繁的双向通信，或对延迟有极高要求。
实际案例分析
案例 1：AI 聊天应用
用户输入 → 服务器处理 → 流式返回文字
↑ ↓
一次性发送 持续推送 tokens选择 SSE：用户只发送一次请求，服务器持续推送生成的文字片段。单向通信，SSE 足够且更简单。
案例 2：实时语音助手
用户说话 → 语音识别 → 大模型处理 → 语音合成 → 播放音频
↑ ↓
音频流 音频流选择 WebSocket：需要双向音频流传输，且对延迟敏感（边说边识别边合成）。
案例 3：在线文档协作
用户 A 编辑 ─┐
├→ 服务器同步 → 用户 B 实时看到变化
用户 B 编辑 ─┘选择 WebSocket：多人同时编辑，需要实时双向同步操作。
决策流程图
需要实时通信？
│
├─ 否 → 普通 HTTP 轮询即可
│
└─ 是 → 需要双向通信？
│
├─ 否（主要是服务器推送）→ SSE
│ 例：AI 流式输出、通知推送、股票行情
│
└─ 是（频繁双向交互）→ WebSocket
例：聊天、游戏、语音、协作编辑总结
| 你的需求 | 推荐技术 |
|---|---|
| AI 大模型流式生成（文本） | SSE |
| 服务器推送通知/数据 | SSE |
| 实时语音/视频处理 | WebSocket |
| 在线游戏/实时协作 | WebSocket |
| 即时通讯/聊天室 | WebSocket |
| 日志/进度流式展示 | SSE |
简单记忆：单向推选用 SSE，双向互动选 WebSocket。