WebSocket连接失败时onerror不触发是因为服务端未响应HTTP Upgrade握手，浏览器等待超时而非进入错误回调；需用curl模拟握手、检查端口/TLS/反向代理配置。
WebSocket 连接失败时 onerror 不触发，只卡在 pending？
这是最常被误判的“连不上”问题：浏览器 DevTools 显示 WebSocket 请求一直 pending，onerror 没调用，onopen 更是遥遥无期。根本原因不是代码写错，而是服务端没响应握手（HTTP Upgrade 失败），浏览器直接等超时，不进错误回调。
实操建议：
- 先用
curl -i -N -H "Connection: Upgrade" -H "Upgrade: websocket" -H "Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==" http://your-api.com/ws手动模拟握手，看返回是否含101 Switching Protocols - 检查服务端是否监听了正确端口、TLS 配置是否匹配（
wss://必须配有效证书，自签名也不行） - 确认反向代理（如 Nginx）已透传
Upgrade和Connection头，常见漏配项：proxy_set_header Upgrade $http_upgrade;和proxy_set_header Connection "upgrade";
HTML5 中 WebSocket 的 readyState 值到底代表什么
readyState 不是“连接中/已连接”的简单二分，它有四个确定值，每个都对应底层 TCP+HTTP 握手状态，误判会导致重连逻辑出错。
关键点：
立即学习“前端免费学习笔记（深入）”；
-
WebSocket.CONNECTING（值为 0）：仅表示new WebSocket(url)已执行，还没收到服务端 101 响应 —— 此时调send()会静默丢弃，不报错 -
WebSocket.OPEN（1）：握手完成，可收发；但网络闪断后不会自动变回 CONNECTING，需靠心跳或onclose感知 -
WebSocket.CLOSING（2）和WebSocket.CLOSED（3）：前者是主动调close()后的中间态，后者才是彻底断开；若服务端强制断连，可能直接跳到 CLOSED，跳过 CLOSING
怎么安全地重连 WebSocket 而不炸掉服务端
盲目轮询 new WebSocket() 是最常见翻车点：页面未关闭时定时重试，用户切到其他标签页再切回来，瞬间涌出几十个并发连接请求，服务端连接数爆表。
靠谱做法：
- 用指数退避（exponential backoff）：首次失败等 1s，再失败等 2s，然后 4s、8s… 上限设为 30s，避免雪崩
- 监听
visibilitychange事件，在页面不可见时暂停重连，可见后再检查readyState决定是否恢复 - 每次新建连接前，先
if (ws && ws.readyState === WebSocket.OPEN) return;，避免残留连接未清理就重复建连 - 服务端必须设连接超时（如 60s 无 ping 自动踢），否则客户端重连风暴会拖垮后端
WebSocket 收发二进制数据时，binaryType 设成 "arraybuffer" 还是 "blob"？
选错直接影响内存和解析效率："blob" 看似省事，但每次 ws.send(blob) 都要触发异步读取，而 "arraybuffer" 是同步零拷贝传输，尤其适合实时音视频帧或 protobuf 序列化数据。
使用建议：
- 默认设
ws.binaryType = "arraybuffer"；需要流式处理大文件时才切"blob" - 接收端拿到
ArrayBuffer后，别直接JSON.parse(new TextDecoder().decode(buf))—— UTF-8 解码可能截断多字节字符，应先用new Uint8Array(buf)判断首字节是否为0x7b（{）再决定走文本还是二进制解析 - 注意 Safari 对
ArrayBuffer的send()支持较晚（iOS 15.4+），旧版本需降级 fallback
