只有 ws.readyState === WebSocket.OPEN（1）才可安全收发数据；0为CONNECTING（连接中）、1为OPEN（就绪）、2为CLOSING（关闭中）、3为CLOSED（已关闭），构造后立即检查无效，须在onopen中确认。

只有 ws.readyState === WebSocket.OPEN 才代表连接真正就绪，可安全收发数据；其他值都不行，直接 send() 会抛 InvalidStateError。

WebSocket readyState 的四个合法值分别代表什么

它不是布尔值，也不是“在线/离线”开关，而是连接生命周期的精确快照：

• WebSocket.CONNECTING（0）：实例已创建，但 DNS、TCP 握手、HTTP Upgrade 等步骤尚未完成；此时调用 send() 必报错
• WebSocket.OPEN（1）：握手成功，通道打通，send() 和 onmessage 都可正常工作
• WebSocket.CLOSING（2）：close() 已被调用（本地或服务端），但关闭帧可能未收完，仍可能收到最后几条消息
• WebSocket.CLOSED（3）：连接彻底终结，不可复用；若要重连，必须 new WebSocket(...) 新建实例

为什么不能 new WebSocket() 后立刻检查 readyState

构造函数是异步发起连接的，new WebSocket(url) 返回瞬间，readyState 几乎总是 0，但连接远未建立——这不是延迟问题，而是设计如此。

WebSocket 8.18.2

WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。

下载

• 轮询 readyState 或用 setTimeout 等固定时间点判断，既不可靠（弱网下超时难定），也浪费资源
• 正确时机在 onopen 回调内：触发即表示状态已稳定为 1，且网络层确认可达
• 错误处理应依赖 onerror：它可能在 CONNECTING 阶段就触发，此时 readyState 通常仍是 0 或已退为 0

send() / close() 前必须做的状态校验

不校验就调用是生产环境 InvalidStateError 的头号来源。

• 发消息前只认 WebSocket.OPEN：if (ws.readyState === WebSocket.OPEN) ws.send(data)
• 允许对 OPEN 或 CLOSING 调用 close()（重复调用无副作用）；但绝不要对 CONNECTING 或 CLOSED 调用
• 老环境（如 Android 4.4 WebView）可能不支持 WebSocket.CONNECTING 等常量，可回退用数字，但务必加注释说明含义

重连逻辑里 readyState 最容易踩的坑

重连不是“看到不是 1 就新建”，而要结合事件和终态判断：

• 仅在 onclose 或 onerror 触发后才启动重连流程
• 重连前先确认 ws.readyState === WebSocket.CLOSED（即 3），避免对仍在 CLOSING（2）的实例重复操作
• 新建实例前，显式设 ws = null，否则旧实例监听器可能残留，导致多次触发 onopen 或内存泄漏
• readyState === 1 不等于“网络通畅”——断网后它可能维持数秒不变，需配合心跳 + onerror + 超时检测综合判断