WebSocket连接失败主因是建立阶段问题，需检查协议匹配、Origin校验、路径参数一致；二进制数据须预设binaryType为'blob'或'arraybuffer'；需实现指数退避心跳保活与状态清理。
WebSocket 连接失败的常见原因和快速排查
绝大多数 WebSocket 通信问题出在连接建立阶段，而不是后续收发消息。浏览器控制台报 WebSocket connection to 'ws://...' failed 时，优先检查这几点：
- 协议必须匹配：前端用
ws://（开发环境）或wss://（生产环境），后端服务必须实际监听对应协议，Nginx 反向代理需显式配置Upgrade和Connection头 - 跨域不是主因：WebSocket 协议本身不受同源策略限制，但浏览器仍会发送
Origin头，后端若校验失败（如未白名单你的域名），会直接拒绝握手 - 路径和查询参数要一致：比如前端连
new WebSocket('wss://api.example.com/ws?token=abc')，后端路由必须能接收并解析该token参数，否则鉴权失败静默断连
onmessage 回调里处理二进制数据容易踩的坑
WebSocket 默认接收文本（string），但传图片、音频或序列化数据时常用 Blob 或 ArrayBuffer。关键点在于：websocket.binaryType 必须提前设置，且不能在连接打开后动态改。
- 设为
'blob'：适合文件上传/下载场景，后续用URL.createObjectURL()预览图片，但注意 Blob 需手动revokeObjectURL - 设为
'arraybuffer'：适合结构化数据（如 Protocol Buffers、自定义二进制协议），用Uint8Array或DataView解析，性能更好 - 错误做法：不设
binaryType就直接接收二进制，结果得到乱码字符串，且无法还原
示例：
const ws = new WebSocket('wss://example.com');
ws.binaryType = 'arraybuffer';
ws.onmessage = (e) => {
if (e.data instanceof ArrayBuffer) {
const view = new DataView(e.data);
console.log('收到长度:', view.byteLength);
}
};
心跳保活与自动重连的实用实现逻辑
浏览器不会主动维持 WebSocket 连接，NAT、代理、防火墙可能在空闲几十秒后切断连接。纯靠 onclose 触发重连远远不够，必须主动探测。
- 服务端发 ping 帧最可靠：WebSocket 协议原生支持
ping/pong帧（浏览器自动响应），但多数 JS 库不暴露该能力；更通用的是应用层心跳：客户端定时发{ type: 'ping' }，服务端立刻回{ type: 'pong' } - 重连不能无脑轮询：首次失败后等 1s，第二次等 2s，第三次等 4s……指数退避，上限建议 30s；同时设置最大重试次数（如 5 次），避免无限卡死
- 重连前务必清理旧状态：清除定时器、取消未完成的
send()、重置readyState判断逻辑，否则可能触发重复连接或InvalidStateError
send() 调用时机与缓冲区溢出风险
WebSocket.send() 不是立即发包，它把数据压入浏览器内部发送队列。当 readyState !== 1（即非 OPEN）时调用会直接抛错；而队列积压过多时，bufferedAmount 持续增长，最终被浏览器强制关闭连接。
立即学习“Java免费学习笔记（深入）”；
- 发消息前必判状态：
if (ws.readyState === WebSocket.OPEN) { ws.send(JSON.stringify(data)); } - 高频发送（如游戏帧同步）要节流：监听
ws.bufferedAmount，超过阈值（如 64KB）就暂停发送，等onopen或onmessage后再恢复 - 大消息拆分：单次
send()超过几 MB 容易触发浏览器限制，应分片 + 序号标识，服务端拼接
真实项目里，连接不稳定、心跳不同步、send 时机失控，这三者叠加最容易导致“看起来连上了却收不到消息”的诡异问题——往往不是代码写错，而是状态管理没跟上连接生命周期。
