为什么前端项目不都采用 WebSocket？

你可能会想：微信、钉钉这些聊天软件，不也是靠类似的技术支撑的吗？它们能支撑上亿用户同时在线，那咱们的业务系统用 WebSocket，不就能统一交互方式、实时性直接拉满了？

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

在前端圈子里面，WebSocket一直自带 “高端感”，甚至有些中小厂在面试中会把 WebSocket 作为技术难点来问。

毕竟，WebSocket 能做到全双工通信，还能让前端和后端像打电话一样实时对话，听上去就是 HTTP 的“终极替代品”。

那问题来了：既然 WebSocket 这么强，为什么今天的 Web 应用没有全面抛弃 HTTP，只用 WebSocket？

你可能会想：微信、钉钉这些聊天软件，不也是靠类似的技术支撑的吗？它们能支撑上亿用户同时在线，那咱们的业务系统用 WebSocket，不就能统一交互方式、实时性直接拉满了？

很遗憾，事情远没有这么简单。

如果你真把所有接口都塞进 WebSocket，不仅不会变轻松，反而会掉进一个又一个大坑。

今天，我们就来拆解一下：

为什么会出现 WebSocket？WebSocket 的优势都有什么？WebSocket 的缺陷都有啥？实际开发中，WebSocket、SSE、HTTP 各自应该怎么选？

为什么会出现 WebSocket？

在 WebSocket 出现之前，前端要想实现“实时通信”，基本只能靠两种老办法：

轮询（Polling）前端每隔几秒发一次请求问：“有新数据吗？”缺点是显而易见的：浪费带宽，延迟还高。长轮询（Long Polling）前端发起请求，服务端不立刻返回，而是等到有新数据才响应。响应完了，前端再发起新的请求。延迟问题解决了一点，但依旧有大量连接在反复创建、销毁。

这两种方案其实都不好。

所以，在 2011 年，WebSocket 协议（RFC 6455）横空出世。

它的核心思想很简单：

先用一次 HTTP 握手（Upgrade），然后“升级”成一条持久化的 TCP 连接。从此以后，前后端可以像发短信一样随时互发消息，不再需要频繁建立 HTTP 请求。

这在当年绝对是革命性的体验：实时性大幅提升，同时 服务器压力也大幅度下降。

也正是因为这样，WebSocket 一度被视为 “Web 实时通信的未来”。

WebSocket 的优势都有什么？

虽然现在大家对 WebSocket 的评价趋于理性，但不得不承认，它依旧有一些“别人替代不了”的独家优势：

1. 所有消息走一条连接，时序可控

传统 HTTP 请求是一次一条通道，并行时序靠队列调度，没法保证严格的先后顺序。

而 WebSocket 不一样：所有请求、响应、通知消息都在同一条连接上传输。

这意味着你能精准掌控消息的时序：谁先谁后，完全由你决定。

2. 一次鉴权，状态长期有效

在 HTTP 世界里，每次请求都得带上 Token、Cookie 等鉴权信息，服务端要一遍遍校验。

WebSocket 则更简单：连接建立时完成一次认证，后续所有消息都基于同一个连接。换句话说，它天然就是“有状态”的通信方式，管理起来省心很多。

看起来是不是很爽？

但很遗憾，优势只有这两条。 剩下的都是问题.....

WebSocket 的缺陷都有啥

光看上面的介绍，你会感觉WebSocket真爽。

但是，如果你真的想要把 所有接口都搬到 WebSocket 上时，很快就会被教育了。

因为 WebSocket 带来的问题，往往比它解决的问题还多：

1. 认证机制不如 HTTP 简单

握手阶段可以带 Cookie 或 Token，但一旦连接建立，后续就是裸 TCP 流了。

想用 Header 做认证？不好意思，已经没有 HTTP 头了。

这就意味着你需要自己在消息体里定义认证字段，或者额外维护一套“请求上下文”。

2. 跨域风险更高

HTTP 有CORS来保护，WebSocket 默认是允许跨域的。

如果不额外校验Origin头，那么就非常容易出现数据泄露的问题。

3. 请求与响应要自己匹配

HTTP 天然是一问一答。

但是，WebSocket 没这个约束，你必须用request_id来区分不同请求的响应，不然消息一乱就麻烦大了。

4. 中间件和生态缺失

HTTP 里日志、监控、路由、缓存都有现成中间件。

但是，WebSocket 世界？几乎得自己造轮子，连调试都麻烦。

5. 部署和代理更复杂

不是所有代理、负载均衡器都默认支持 WebSocket。

配置不当的话，Upgrade头可能被吃掉，导致连接直接挂掉。

所以说，WebSocket 很酷，但坑点也很硬核。

你要是把 CRUD 接口都放进去，绝对是“自找麻烦”。

WebSocket、SSE、HTTP 各自应该怎么选

那么根据以上内容，大家应该就可以知道：WebSocket 是不可以无脑使用的。

那么具体应该怎么用呢？

1. 常规请求：老老实实用 HTTP

像用户登录、商品下单、列表查询这类标准 CRUD 操作，HTTP 永远是最优解。

2. 单向推送：优先 SSE（EventSource）

如果你的场景是服务端推消息给前端，比如：

系统通知订单进度更新股票/舆情行情

这类单向实时推送，SSE 更合适：

3. 双向交互：再考虑 WebSocket

只有在确实需要双向通信的时候，才该上 WebSocket，比如：

聊天系统在线协同编辑实时白板、游戏对战

这种场景下，客户端要告诉服务端“我订阅了哪个频道”，服务端再有针对性地推送。

给大家一个表单，来更清楚的展示 websocket、SSE、长轮询、HTTP 的使用场景：

图片