WebSocket 连接失败：检查 new WebSocket() 的 URL 格式
浏览器里 new WebSocket() 报错 “Error in connection establishment”，八成是协议或地址写错了。WebSocket 不是 HTTP，不能用 http:// 或漏掉协议前缀。
- 正确写法必须是
wss://example.com/ws（生产）或ws://localhost:8080（开发），ws和wss都要小写，且不能带路径参数如?token=xxx（得走headers或连接后发认证帧） - Chrome 控制台 Network 标签页里看不到
ws://请求？那是正常的——它不归 HTTP 请求列表管，得看 “WS” 子标签 - 如果后端跑在 Nginx 后面，确认已配好 WebSocket 升级头：
proxy_http_version 1.1、proxy_set_header Upgrade $http_upgrade、proxy_set_header Connection "upgrade"
onmessage 收不到数据：确认服务端发送的是文本帧，不是二进制
WebSocket 默认接收文本帧（typeof event.data === 'string'），但有些后端库（比如 Python 的 websockets）默认发 bytes，浏览器就静默丢弃。
- 前端加个类型判断更稳：
ws.onmessage = (e) => { const data = typeof e.data === 'string' ? JSON.parse(e.data) : JSON.parse(new TextDecoder().decode(e.data)); }; - Node.js 的
ws库发消息时用ws.send(JSON.stringify(obj))，别用ws.send(Buffer.from(...))，除非你明确需要二进制传输 - 调试时在 Chrome 的 WS Frame 标签页里点开每条记录，看 “Data” 列显示的是 “Text” 还是 “Binary” —— 如果是后者，前端没处理就会卡住
连接自动断开：心跳机制不是可选项，是必做项
多数代理、负载均衡、NAT 设备会在 60 秒无流量后主动关掉空闲 WebSocket 连接，这不是 bug，是网络常态。
- 不要依赖
ws.readyState === WebSocket.OPEN就认为链路还活着；得自己定时发 ping 帧，比如每 45 秒ws.send('ping')，后端回'pong'，前端收到就刷新最后通信时间 - 别用
setInterval盲发——如果上一个 ping 还没收到 pong，下一个又发出去，会堆积；建议用setTimeout链式触发，收到 pong 再启动下一轮 - 注意：浏览器不暴露原生 ping/pong 帧监听，
onmessage收到的'pong'是后端手动 send 的字符串，不是底层协议帧
页面刷新后状态丢失：WebSocket 不支持自动重连，得自己兜底
刷新页面瞬间，WebSocket 实例销毁，onclose 触发，但不会自动重建——用户看到的就是白屏或假死。
立即学习“前端免费学习笔记（深入）”；
- 简单策略：在
onclose里用指数退避重试，比如第 1 次等 1 秒，第 2 次等 2 秒，第 3 次等 4 秒……最多试 5 次，避免雪崩 - 重连前先检查
navigator.onLine，离线时别瞎试；重连成功后，记得补发未确认的关键消息（比如聊天里的“已读回执”） - 别把
WebSocket实例挂全局变量上试图跨刷新复用——不可能，localStorage里存的只是字符串，不是连接句柄
真正麻烦的从来不是第一次连上，而是连上之后的 3 分钟：网络抖动、服务重启、token 过期、心跳超时、消息乱序……这些细节堆起来，才决定实时功能到底“实不实”。
