websocket 连接失败应以 onclose 为核心处理，onerror 仅用于日志上报；握手失败时 onclose 立即触发且 code=1006；需主动超时检测 connecting 状态、状态锁防重复连接、send 前校验 readystate。
WebSocket 连接失败不能只靠 onerror 捕获，它既不触发于握手失败（如 401/404/502），也不能反映真实断连原因。真正可靠的异常识别和处理，必须围绕 onclose 展开，并辅以连接阶段的主动检测和状态管理。
握手失败：看 Network 面板里的 101 状态码
如果 WebSocket 根本没连上，浏览器 Network → WS 标签页为空，或出现 HTTP 状态码（如 401、404、502），说明协议升级被拦截——onerror 不会触发，onclose 会立即触发且 event.code === 1006、reason 为空。
- 检查页面协议与 WebSocket 协议是否匹配：HTTPS 页面必须用
wss://，HTTP 页面不能用wss:// - 确认 Nginx 等反代配置了三行关键头：
proxy_http_version 1.1、proxy_set_header Upgrade $http_upgrade、proxy_set_header Connection "upgrade" - 服务端必须校验
Sec-WebSocket-Key并返回合法的Sec-WebSocket-Accept，响应体不能有额外空格或字符
onerror 只做日志，不做决策
onerror 是底层网络异常信号（如 DNS 失败、TLS 中断、本地防火墙拦截），不是连接终态。它可能在 readyState === 0（CONNECTING）时触发，此时调用 ws.close() 会抛 InvalidStateError。
- 仅用于上报：记录
event.type和时间戳，不依赖其内容判断失败类型 - 不要在
onerror中修改 UI（如显示“连接失败”），也不要在其中启动重连 - 调试时配合 DevTools 的 Network → WS → Frames 查看握手帧和关闭帧
onclose 才是连接终态，靠 code 和 reason 判断
所有连接终止（包括握手失败、网络中断、服务端关闭）最终都会触发 onclose。关键看 event.code：
-
1000：正常关闭，无需重连 -
1006：最常见异常断连（TCP 被 RST），无reason，需重连 -
1001：端点离开（如页面卸载），通常不重连 -
4001–4999：服务端自定义错误码，需约定含义（如 4001=鉴权过期）
event.reason 是否有值取决于服务端是否设置了 Sec-WebSocket-Close-Reason，Nginx 默认不透传，不能假设它一定存在。
连接阶段加超时和状态锁，防假连接
新建 WebSocket 后，若长时间卡在 CONNECTING（readyState === 0），大概率握手卡住。需主动超时控制：
- 设置
setTimeout，比如 5 秒后检查readyState，非OPEN则close()并标记失败 - 用布尔变量（如
isConnecting = true）防止onclose多次触发重复 new WebSocket - 重连必须带指数退避（1s→2s→4s…）和最大次数限制（如 5 次），避免雪崩
- 每次
send()前必须检查ws.readyState === WebSocket.OPEN，否则直接报错
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
