标题|Home

WebSocket 不是不好，而是被严重高估了它的"万能性"。 它解决了一类问题，同时带来了另一批问题。大多数 Web 场景用 HTTP 反而是更明智的选择。

一、先破一个认知误区

很多人觉得 WebSocket 比 HTTP "更先进"，HTTP 是"老东西"，WebSocket 是"未来"。

这个想法完全错了。

HTTP 和 WebSocket 是两种适合不同场景的工具，就像锤子和螺丝刀，不存在谁淘汰谁的问题。拿锤子拧螺丝，不是锤子不行，是你用错了。

二、WebSocket 的致命缺陷，一条一条说清楚

1. 无状态的 HTTP 是优势，不是缺点

HTTP 最被人诟病的一点——"无状态"——恰恰是它最大的工程优势。

每一个 HTTP 请求都是独立的，服务器处理完就扔掉了，不需要记住你是谁。这带来了一个极其重要的特性：天然支持水平扩展。

你有 100 台服务器，用户的请求打到任意一台都能正确响应。负载均衡器随便轮询，没有任何问题。

WebSocket 呢？连接是有状态的，一旦建立，这条连接就"粘"在某一台服务器上了。用户 A 连在机器 1 上，你的负载均衡器就不能随意把它的后续消息打到机器 2——因为机器 2 根本不知道这条连接的状态。

这意味着什么？你的整个后端架构要为 WebSocket 做专门适配。

要么引入粘性会话（Sticky Session），要么引入一个中心化的消息总线（Redis Pub/Sub、Kafka），让所有机器共享连接状态。复杂度直接上了一个台阶。

2. 连接是稀缺资源，不是免费的

HTTP 请求是短连接，用完即走，服务器资源立刻释放。

WebSocket 是长连接，只要用户开着页面，连接就一直占着。

假设你的服务有 100 万用户同时在线，全部 WebSocket 长连接，那就是 100 万个并发连接同时压在你的服务器上。每个连接都要占用文件描述符、内存、心跳维护的 CPU……

这不是不能做，微信、飞书这类 IM 产品确实在做，但他们为此专门维护了连接网关集群，这是一套独立的基础设施，有专门的团队在维护。你以为微信后端是一套统一的 WebSocket 服务？不是，那是几百个工程师维护的分布式系统。

对于一个普通的业务系统，为了"统一通信协议"引入这套复杂度，完全得不偿失。

3. 中间链路的兼容性问题，比你想象的严重

HTTP 已经跑了几十年，全球所有的网络设备——路由器、防火墙、CDN、反向代理、企业内网——都对它有完美支持。

WebSocket 就不一样了。

WebSocket 虽然复用了 HTTP 的握手，但升级协议后的行为跟普通 HTTP 完全不同。很多企业内网的防火墙、某些运营商的中间设备，会强行切断长时间没有数据的 TCP 连接，或者压根不认识 WebSocket 协议，直接丢包。

这就是为什么 WebSocket 客户端必须实现心跳机制，定期发 ping/pong 保活。你以为这是小事，但在工程上意味着：

• 客户端要实现心跳逻辑
• 服务端要处理心跳超时和连接清理
• 要实现断线重连，并且重连时要恢复状态
• 网络抖动时要处理消息丢失和重复推送

每一条都是工作量，每一条都是潜在的 bug。

4. 调试、监控、运维成本大幅上升

HTTP 的调试简单到极致：打开 Chrome DevTools，Network 面板，所有请求一目了然，每个请求的入参、出参、耗时、状态码清清楚楚。

WebSocket？DevTools 里只能看到一条"101 Switching Protocols"，之后的所有消息混在一个 Messages 标签里滚动。你要在几百条消息里找到某个异常，痛苦程度不亚于在 access log 里肉眼找 bug。

更别提：

• HTTP 有成熟的 APM 接入方案，链路追踪开箱即用
• WebSocket 的消息没有天然的 Request ID，链路追踪要自己实现
• HTTP 的 RESTful 语义清晰，WebSocket 的消息协议要自己设计和维护

5. 缓存体系完全失效

HTTP 有一套成熟的缓存体系：CDN 缓存、浏览器缓存、Cache-Control、ETag……对于读多写少的数据，一个接口加上合适的缓存头，可以把 99% 的请求挡在 CDN 层，后端压力小到忽略不计。

WebSocket 是实时双向流，没有缓存这个概念。所有消息都要打到服务端处理。

三、回到你说的那个场景

调一个接口获取列表数据，用户长时间停留页面，数据变动了怎么办？

这个问题有很多解法，按复杂度递增：

轮询（Polling）：每隔 N 秒请求一次。简单粗暴，适合数据更新不频繁、实时性要求不高的场景。

长轮询（Long Polling）：请求发出去，服务端 hold 住，有数据更新了再返回。实时性更好，实现成本也不高。

SSE（Server-Sent Events）：服务端单向推送，基于 HTTP，天然支持断线重连，浏览器原生支持。适合服务端推送、不需要客户端上行的场景，比 WebSocket 轻量得多。

WebSocket：真正需要双向实时通信时才用，比如聊天、协同编辑、实时游戏。

你说的那个场景——列表数据变动通知——用 SSE 就够了，完全不需要 WebSocket。

四、什么时候才该用 WebSocket？

• 聊天、弹幕、实时评论——需要双向通信
• 协同文档——多人同时编辑，需要实时同步操作
• 实时游戏——高频双向数据交换
• 股票行情、实时监控大屏——高频服务端推送（其实 SSE 也够）

判断标准只有一个：你的场景是否真的需要客户端主动向服务端高频发送数据，同时服务端也在高频下发数据？ 如果只是服务端推，用 SSE。如果请求频率不高，用轮询或长轮询。只有真正的双向高频通信，才上 WebSocket。