WebSocket连接失败主因是服务端未启动、协议不匹配或浏览器拦截；需核对ws/wss协议、检查Network中101状态码、确保后端正确响应升级请求，并避免file://协议下使用。
WebSo
直接 new WebSocket() 报错或连接立刻关闭，大概率不是代码写错了，而是服务端没起来、URL 协议不匹配，或者浏览器被拦截。先确认 ws:// 或 wss:// 和后端实际暴露的协议一致；本地开发时如果后端用 http://localhost:3000，前端却连 ws://127.0.0.1:8080，跨域+协议+端口全错，必然失败。
- 检查浏览器控制台 Network 标签页里 WebSocket 请求的状态码：
101 Switching Protocols才算成功握手，否则看 Response Headers 有没有Sec-WebSocket-Accept - 确保后端已正确响应 WebSocket 升级请求（比如 Node.js 的
ws库需显式server.handleUpgrade()） - Chrome 浏览器在非
http://或https://页面（如file://）下会静默拒绝ws://连接，必须走本地服务器
onmessage 回调里如何安全解析 JSON 数据
WebSocket.onmessage 接收到的 event.data 是 string 或 Blob，不是自动 JSON 解析后的对象。直接 JSON.parse(event.data) 可能抛错，尤其当服务端发来非 JSON 字符串（比如心跳 ping/pong、二进制帧、调试日志）时。
- 始终用
try...catch包裹JSON.parse()，避免整个回调崩溃 - 提前判断
typeof event.data === 'string'，跳过Blob或ArrayBuffer类型（除非你明确要处理二进制） - 服务端最好统一加个
type字段，比如{ "type": "message", "payload": {...} }，前端按 type 分发逻辑，而不是硬解析所有 data
如何避免重复连接和自动重连失控
页面刷新、网络抖动、服务端重启都会导致连接断开。但 onclose 里直接 new WebSocket() 会引发无限重连风暴，尤其配合未加延迟的递归调用。
- 用布尔标志位（如
let isConnecting = false）防止onclose多次触发新建实例 - 重连前加指数退避：第一次等 1s，第二次 2s，第三次 4s……上限建议 30s，避免压垮服务端
- 限制最大重连次数（比如 5 次），之后应提示用户“连接异常”，并提供手动重试按钮（
reconnectBtn.addEventListener('click', initWS)） - 在
onopen中清除之前的重连定时器，避免旧定时器在新连接建立后仍执行
发送消息前必须检查 readyState
WebSocket.readyState 不是永远等于 WebSocket.OPEN。页面刚加载时是 0（CONNECTING），断连瞬间变成 0 或 3（CLOSED），此时调用 send() 会直接报错 InvalidStateError，且不会进入 onerror。
- 每次
send()前必须判断：if (ws.readyState === WebSocket.OPEN) { ws.send(...) } - 如果处于
CONNECTING（0）状态，可把消息暂存到队列（pendingMessages.push(msg)），并在onopen中批量发送 - 不要依赖
onerror捕获 send 失败——它只对底层传输错误有效，readyState不对时根本不会触发
WebSocketClient 类，而不是裸用原生 API。
