WebSocket异常不能靠try/catch捕获，必须分阶段用事件监听：onerror仅记录日志不作判断；onclose才是诊断核心，重点依据event.code（如1006表示TCP强制中断、1000为正常关闭、4001–4999为自定义业务码）；握手失败直接触发onclose而非onerror；需配合Network面板和主动心跳探测确保连接真实可用。
WebSocket 的异常不能靠 try/catch 捕获，因为连接过程完全异步，构造函数 new WebSocket() 立即返回，错误发生在后台线程中。真正能用的捕获方式只有事件监听，但必须分场景、分阶段使用不同事件，不能只盯 onerror。
onerror 只记日志，不作判断
onerror 是一个兜底信号，它不带错误码、不报原因，控制台打印出来只是 Event {isTrusted: true}。它可能由 DNS 失败、TLS 中断、本地防火墙拦截等触发，但也可能在握手失败后完全不触发。所以：
- 只用来上报原始事件类型和时间戳，例如：
console.warn('ws.onerror triggered at', Date.now()) - 不要在其中调用
ws.close()，此时readyState很可能是 0（CONNECTING），会抛InvalidStateError - 不要用它更新 UI 状态，比如弹“连接失败”，这类反馈应统一由
onclose驱动
onclose 才是诊断核心，重点看 code
连接终结一定走 onclose，它的 event.code 是唯一可信赖的根因标识：
-
code === 1006：最常见，代表 TCP 层被强制中断（Nginx 断连、iOS 后台回收、NAT 超时），reason通常为空，onerror完全静默 -
code === 1000：正常关闭，比如页面卸载或主动调用ws.close() -
code === 4001–4999：服务端自定义业务码，需配合reason（如果服务端透传了）理解上下文 -
code === 1001：端点离开，常见于浏览器关闭、标签页隐藏
注意：握手失败（如服务端返回 401/404/502）不会进 onopen，而是直接触发 onclose，且多数情况 code 也是 1006。
Network 面板是真实错误的源头
JavaScript 层拿不到具体网络错误（如 net::ERR_CONNECTION_REFUSED），那是浏览器控制台专用提示，脚本不可读。要定位真实问题，必须打开 DevTools → Network → Filter 输入 ws：
- 没看到连接条目 → URL 协议错（用了
http://没用ws://或wss://）、跨域被拦截、DNS 不可达 - 条目状态为
failed或canceled→ 查Initiator，常是脚本里调了ws.close()或页面卸载导致 - 有记录但响应头无
Sec-WebSocket-Accept或状态码不是101→ 服务端拒绝升级，查鉴权、Origin 校验、子协议匹配等问题
主动探测比被动监听更可靠
弱网下 readyState === OPEN 可能是假象，“连接活着但发不出去”很常见。必须自己加心跳：
- 连接打开后，每 25–30 秒发一次
{"type":"ping"}，并设 5–8 秒超时等待pong - 超时未响应，立即
ws.close(4999, 'heartbeat timeout')，再触发重连 - 重连前检查
ws.readyState：是0就跳过，是1先close(1000)再建新连接 - 用指数退避控制重连节奏，例如第
n次延迟1000 × 2ⁿ⁻¹毫秒，上限 5 次
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
