WebSocket 的 error 事件仅作警报，不提供错误详情；需结合 onopen/onclose、readyState、Network 面板及主动心跳探测定位异常。
监听 WebSocket 的 error 事件本身很简单，但**它不能告诉你错在哪**——它只是个“警报器”，不带错误详情。真正捕获和定位通信异常，得靠组合策略：监听 + 状态检查 + 网络工具 + 主动探测。
onerror 只是入口，别指望它返回错误信息
onerror 回调接收的是一个空的 Event 对象，没有 message、code 或 stack。打印出来通常是 Event {isTrusted: true}。它只表示“出事了”，可能发生在：
- DNS 失败（URL 写错、域名不可达）
- TCP 连接被防火墙或代理中断
- 服务端拒绝握手（鉴权失败、协议头缺失）
- 浏览器策略拦截（比如
http://页面尝试连wss://）
真正有用的线索藏在 onopen/onclose 和 readyState 里
比 onerror 更有诊断价值的是连接生命周期信号：
-
onopen触发 → 握手成功，此时readyState === 1 -
onclose触发时看event.code：-
1006：最常见，代表“异常关闭”，基本等于网络断开或服务崩溃 -
4001–4999：服务端自定义业务码（需主动约定） -
event.reason可能含服务端提示（非所有浏览器支持）
-
- 连接未打开就报
error，立即检查：- URL 协议是否为
ws://或wss://（不是http://） - 域名和端口是否可访问
- 当前页面是否符合混合内容策略（如 HTTPS 页面不能连 WS）
- URL 协议是否为
必须配合浏览器 Network 面板确认底层状态
仅靠 JS 事件远远不够，要打开 DevTools → Network → Filter 输入 ws：
- 如果列表里根本没出现 WebSocket 条目 → 连接请求压根没发出去，重点查 URL 和跨域限制
- 如果条目存在但状态是
failed或canceled→ 点开看Headers：- 响应状态码是否为
101 Switching Protocols - 响应头中是否有
Sec-WebSocket-Accept - 看
Initiator，常能发现是脚本某处调用了ws.close()或页面卸载导致
- 响应状态码是否为
加心跳和手动状态检查，让异常更早暴露
等 onerror 或 onclose 触发再响应，已经滞后。建议主动管理：
- 连接建立后启动定时
ping（例如每 25 秒发"ping"） - 等待服务端回
"pong"，超时或连续 2 次无响应即判定异常 - 重连前检查
ws.readyState：-
0（CONNECTING）→ 当前正在连，避免重复发起 -
1（OPEN）→ 正常，无需动作 -
3（CLOSED）→ 已失效，可安全新建实例
-
