websocket的error事件仅为兜底告警，无具体错误信息；真正诊断需结合onopen/onclose事件、readystate状态、network面板查看101响应及sec-websocket-accept头，并辅以心跳探测和主动状态检查。
WebSocket 的 error 事件本身不会提供具体错误原因，它只是一个“兜底告警”，触发时通常已无法获取原始错误细节。排查通信故障不能只靠监听 error，而要结合连接生命周期、状态检查和网络层辅助手段。
监听 error 事件只是第一步，但别指望它告诉你错在哪
WebSocket 对象的 error 事件是 Event 类型，没有 message、code 或 stack 属性，控制台打印出来往往只有 Event {isTrusted: true}。它只表示“某个环节出问题了”，可能是：
- DNS 解析失败（URL 写错或域名不可达）
- TCP 连接被中间设备（防火墙、代理）重置
- 服务端拒绝握手（如鉴权失败、协议不匹配）
- 浏览器策略拦截（混合内容、CORS 不适用但 WebSocket 本身不走 CORS）
真正有用的排查线索藏在 onopen/onclose 和 readyState 里
比 error 更有诊断价值的是连接建立和关闭时的状态反馈：
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
-
onopen触发 → 表明握手成功，此时readyState === 1 -
onclose触发时，检查event.code和event.reason：
•code = 1006：最常见，代表“异常关闭”，通常对应网络中断或服务端崩溃；
•code = 4001–4999：自定义业务码（需服务端主动发送）；
•reason可能含服务端返回的简短提示（非所有浏览器都支持） - 连接未打开前就报
error，立即检查ws.url是否合法、是否用了http://而非ws://或wss://
配合浏览器开发者工具定位真实瓶颈
仅靠 JS 事件不够，必须借助 DevTools：
- 打开 Network 面板 → Filter 输入
ws，找到 WebSocket 连接项； - 点击该条目 → 查看 Headers：确认请求 URL、状态码（应为
101 Switching Protocols）、响应头中是否有Sec-WebSocket-Accept； - 若没出现在 Network 列表中，说明连接根本没发出去 → 检查 URL 协议、端口、跨域限制（如 localhost 调用非本地服务）；
- 若有连接记录但状态为
failed或canceled，展开看 Initiator，常能发现是脚本某处调用了ws.close()或页面卸载导致。
加一层心跳与手动状态探测更可靠
依赖 error 事件被动捕获太滞后。建议主动管理连接健康度：
- 连接打开后启动定时
ping（发一个简单消息如"ping"），等待服务端回"pong"； - 连续 2–3 次无响应，视为连接异常，主动
ws.close()并尝试重连； - 重连前检查
ws.readyState：
•0（CONNECTING）→ 等待或取消当前连接；
•1（OPEN）→ 正常，无需重连；
•2/3（CLOSING/CLOSED）→ 执行新建连接逻辑。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
