陆家贤做实时功能做到现在，JavaScript连接WebSocket这一关，几乎每个前端工程师都要过。聊天消息、业务告警、行情刷新、远程控制台，只要数据需要从服务器主动推到浏览器，你就得new一个WebSocket实例，而不是让用户手动刷新页面去轮询。我最早是从轮询转过来的，踩了不少协议、机制和浏览器环境的坑。这篇文章围绕“JavaScript连接WebSocket”这个主题，先把连接背后的协议原理讲明白，再给出一套可以直接抄进生产项目的连接和封装方案，最后重点梳理那些让连接莫名其妙断掉、让页面卡死、让服务端收不到消息的真实问题。如果你是正在做前端实时功能、被WebSocket各种诡异报错困扰的开发者，这篇应该能帮你少走很多弯路。
1. 项目思路：为什么只推荐用WebSocket做实时双向通信
1.1 一个轮询翻车案例
我第一次认真考虑WebSocket，是在一个数据大屏项目里。需求本身不复杂：服务端每隔几秒推送一组最新的业务指标，前端不需要用户操作就能看到变化。当时为了赶进度，我直接用了setInterval加fetch，每5秒请求一次最新数据，前端确实能“动”起来。但上线当天就出了岔子，用户习惯同时开好几个标签页，每个标签页都独立跑着一个定时器向接口发起请求，高峰时接口每秒几十个请求，数据库连接池被打满，服务端日志里全是超时。
更尴尬的是，轮询根本不是“实时”。服务端数据在1秒时已经变化，客户端可能要到5秒后的下一次请求才能看到，中间隔了整整一个周期。如果缩短轮询周期，带宽和服务器压力又会成倍上涨。后来我把这块改成了JavaScript连接WebSocket的方式，服务端一旦有数据更新就直接推向页面，标签页数量对服务端的压力也不再是线性增长，这才算从根上把问题解决。
1.2 WebSocket解决的四个具体痛点
轮询只是其中一个反面例子。在日常开发里，WebSocket之所以被广泛使用，是因为它一次性解决了几个关键问题。
第一是主动推送。HTTP的本质是请求-响应模型，服务端在没有收到请求时不能主动把数据发给客户端。WebSocket建立连接后就变成了真正的全双工通道，服务端可以随时向客户端写数据，不需要客户端反复来问。
第二是低延迟。轮询的实时性取决于轮询间隔，而WebSocket的数据帧一旦到达就在毫秒级触发客户端回调，实时性有本质提升。
第三是省流量。HTTP轮询每次请求都要带上大量请求头、Cookie等信息，哪怕服务端没有新数据也要完整走一遍。WebSocket连接建立之后，后续消息都是轻量帧，头开销非常小。
第四是连接可复用。同一个WebSocket连接可以承载用户登录、业务消息、心跳检测、服务端控制指令等所有类型的实时数据，避免为不同功能建立多套HTTP连接。
1.3 同类方案对比，为什么是WebSocket而不是SSE
很多刚接触实时通信的读者会问，服务端推送用SSE（Server-Sent Events）不也可以吗？确实可以，但要区分场景。
| 对比项 | HTTP轮询 | SSE | WebSocket |
|---|---|---|---|
| 通信方向 | 客户端发起，服务端响应 | 服务端单向推送 | 全双工双向通信 |
| 实时性 | 取决于轮询间隔 | 高 | 高 |
| 浏览器自动重连 | 无 | 内置自动重连 | 需要自己实现 |
| 请求头开销 | 每次请求都很大 | 连接后较小 | 连接后很小 |
| 服务端实现难度 | 低 | 低 | 中高 |
| 适合场景 | 低频数据、接口兼容 | 服务端单向下发状态 | 聊天、协同、游戏、控制指令 |
SSE适合服务端单方向推送进度的场景，比如任务状态通知、日志流展示，它走的是普通HTTP，部署上更省心。但一旦客户端也需要主动向服务端发送高频数据，比如聊天消息、鼠标协同操作、遥控指令，SSE就不够用了。这时候JavaScript连接WebSocket就成了最直接的方案，因为它把上行和下行都打通了。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 连接前必须吃透的协议机制与概念
2.1 一次WebSocket握手，客户端和服务端在做什么
很多人new了WebSocket之后，只关心能不能收到消息，却没有理解握手过程。结果一旦出问题，连排查方向都没有。
JavaScript里执行new WebSocket(url)时，浏览器会自动向服务端发送一个HTTP Upgrade请求，请求头大约长这样：
http复制GET /ws HTTP/1.1
Host: api.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==
Sec-WebSocket-Version: 13
Origin: https://example.com
服务端收到这个请求后，如果确认支持WebSocket协议，会计算出一个Sec-WebSocket-Accept值并返回状态码101，表示协议切换成功。从这一刻开始，这条TCP连接不再按照HTTP规则收发数据，而是使用WebSocket的帧格式进行双向通信。
我在实际项目里排查问题时，第一步就是看服务端是否返回了101。如果返回的是200、400、403甚至502，那根本不是连接“断开”的问题，而是握手阶段就没成功，后端需要按普通HTTP请求来排查。
2.2 readyState连接状态机，写重连逻辑必须掌握
WebSocket实例里有一个readyState属性，很多开发者只在调试的时候看一眼，却没利用好它。理解这个状态机对写稳定连接特别重要。
javascript复制WebSocket.CONNECTING // 0，连接尚未建立
WebSocket.OPEN // 1，连接已建立，可以收发消息
WebSocket.CLOSING // 2，连接正在关闭
WebSocket.CLOSED // 3，连接已经关闭或根本无法建立
我通常在封装连接管理时，会用readyState判断当前连接是否可复用。比如用户点击“重连”按钮，如果发现readyState === WebSocket.OPEN，就