websocket连接失败常见原因包括服务端未启动、协议/端口错误、连接被拒绝；定位需检查URL协议、服务状态、防火墙、反向代理配置，并利用chrome Network→WS调试帧收发。
WebSocket连接失败的常见报错和定位方法
直接 new WebSocket() 却得不到 open 事件？大概率是服务端没启动，或 URL 协议/端口不匹配。浏览器控制台里看到 Failed to construct 'WebSocket': The URL's scheme must be either 'ws' or 'wss'，说明你用了 http:// 或漏写了协议前缀。
真实开发中更常遇到的是 WebSocket connection to 'ws://localhost:8080' failed: Error in connection establishment: net::ERR_CONNECTION_REFUSED——这代表客户端连得上域名，但目标端口没监听，检查后端是否已运行、防火墙是否放行、反向代理（如 nginx）是否把 Upgrade 头透传了。
-
ws://用于开发环境，wss://是生产必需，HTTP/2 环境下不能混用 - Chrome 控制台的 Network → WS 标签页可查看帧收发详情，右键某条连接选 “Inspect” 能看到原始消息
- 服务端若返回非 101 状态码（比如 400），浏览器不会触发
onerror，而是直接关闭并触发onclose，错误码为1006
发送消息前必须确认 readyState 是 OPEN
WebSocket.readyState 有四个值：0（CONNECTING）、1（OPEN）、2（CLOSING）、3（CLOSED）。很多人在 onopen 回调外就调用 send()，结果抛出 InvalidStateError: Failed to execute 'send' on 'WebSocket': Still in CONNECTING state。
安全做法不是靠延时，而是封装一个带状态检查的发送函数：
立即学习“Java免费学习笔记（深入）”；
function safeSend(ws, data) { if (ws.readyState === WebSocket.OPEN) { ws.send(data); } else if (ws.readyState === WebSocket.CONNECTING) { ws.addEventListener('open', () => ws.send(data), { once: true }); } }- 不要在
onmessage里反复调用send()而不检查状态，重连逻辑未就绪时容易堆积失败 -
jsON.Stringify()后再send()是常规操作，但注意有些服务端要求二进制帧（ArrayBuffer），此时需设ws.binaryType = 'arraybuffer'
如何正确处理断线与自动重连
网络抖动、服务重启、Nginx 默认 60s 超时都会导致连接中断。仅监听 onclose 不够——它不区分是主动关闭还是异常断开。关键看 Event.code 和 event.reason：
- code
1000表示正常关闭；1006是异常关闭（如服务宕机）；1011通常是服务端内部错误 - 不要在
onclose里立即重连，先加个退避延迟（如 1s → 2s → 4s），避免雪崩式重连请求压垮服务 - 重连前务必
ws.close()并置空引用，否则旧实例可能还在触发onmessage导致内存泄漏
简单重连逻辑示例：
let ws; let reconnectDelay = 1000; function connect() { ws = new WebSocket('wss://api.example.com/ws'); ws.onopen = () => { reconnectDelay = 1000; }; ws.onclose = () => { if (ws.readyState !== WebSocket.CLOSED) return; setTimeout(connect, reconnectDelay); reconnectDelay = Math.min(reconnectDelay * 2, 30000); }; }
接收消息时怎么避免 json 解析崩溃
onmessage 的 event.data 可能是 string、ArrayBuffer 或 Blob，取决于服务端发什么类型。如果服务端发的是纯文本但偶尔夹杂乱码，或前端误当 JSON 解析，就会触发 SyntaxError: Unexpected Token。
- 始终用
try/catch包裹JSON.parse()，不要假设每次都是合法 JSON - 服务端应统一约定消息结构，例如外层用
{ type: 'chat', payload: {...} }，前端先判type再分发处理，而不是每个地方都硬解析 - 如果服务端支持，可在握手阶段协商子协议（
new WebSocket(url, ['json-v1'])），但这只是语义标记，不改变实际传输格式
解析防护示例：
ws.onmessage = (event) => { if (typeof event.data !== 'string') return; try { const msg = JSON.parse(event.data); handleMessage(msg); } catch (e) { console.warn('Invalid JSON received:', event.data); } };复杂业务里，WebSocket 往往要和认证、心跳、消息去重、离线缓存这些环节咬合，光连上只是起点。最容易被忽略的是服务端对并发连接数的限制和客户端未清理的事件监听器——它们不会立刻报错，但会在长时间运行后突然暴露。