前几天复习 WebSocket 时，看到文章说它适用于“实时通信”。这让我产生了好奇：AI 聊天甚至语音通话（如豆包）也算实时通信，为什么 OpenAI、Anthropic (Claude)、DeepSeek 等主流厂商几乎清一色采用了 SSE (Server-Sent Events)？是 WebSocket 不够强吗？ 我抱着这种好奇继续探索。
1. 业务模型决定技术选型：单向 vs 双向
这是最根本的原因，技术是为业务服务的，最适合的才是最好的，你可能更强，但它更适合、更稳定。
- WebSocket：全双工通信，适合高频双向交互，例如打游戏，协同编辑。
- SSE：单工通信（服务器->客服端）
再看下AI聊天的真实数据流向：
- 用户->服务器 ：发送一次请求。频率低，几秒，甚至几分钟一次。
- 服务器->用户：持续流式返回生成的Token，数据量大，持续数秒到数十秒。
结论： 在这种一次请求，时间长且连续的推送下，WebSocket强大的双向能力为了维护一个低频的上行通道（用户->服务器），去维护一个复杂的双向机制，就有些多余了。属实是悟空开个超级赛亚人打个拿巴。
2. 开发复杂度：原生重连 vs 手动造轮子
稳定性对AI产品非常重要。 遇到网络波动，SSE是浏览器原生支持断线自动重连，而WebSocket还得写心跳检测+指数退避重连，代码量大还容易出bug。
3. 兼容性强：HTTP
SSE基于标准HTTP/HTTPS，一个80一个443端口，大多数公司，学校防火墙策略都是允许的，能够轻松穿过防火墙和代理。
WebSocket 有时经常被严格网络环境拦截，导致连接失败。虽然也可以配置在80/443端口上，但是很多旧系统都会都自定义放在8080，9000端口上，这些端口在企业内网上都是被禁止通过的。
4.总结
AI聊天只需要单向文本流，SSE更轻，更稳，代码里更少，除非要做在线游戏或者协同编辑，否则别盲目上WebSocket。但如果是豆包打电话的话，这种纯语音通话场景，网上搜了下，既不是SSE也不是WebSocket而是WebRTC。
