WebSocket收不到数据需检查onmessage绑定时机与方式、binaryType设置、重连策略及消息处理节奏。应统一在onopen中绑定监听，设对binaryType，用指数退避重连，并节流高频消息。
WebSocket 连接建立后收不到数据？检查 onmessage 是否被覆盖或未绑定
很多情况下，页面看似成功连接了 WebSocket，但 onmessage 回调始终不触发。常见原因是：多次赋值 ws.onmessage 导致前一次监听被覆盖；或在 ws.onopen 之外、连接未就绪时就尝试绑定；又或者监听函数里抛错中断了后续执行。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 统一在
ws.onopen回调内绑定onmessage，确保连接已就绪 - 避免重复赋值，改用
ws.addEventListener('message', handler)更安全 - 在
onmessage内加try...catch，防止解析失败（如非 JSON 字符串）导致静默退出
后端发来的数据是字符串还是 ArrayBuffer？binaryType 必须提前设对
WebSocket 默认以 DOMString 接收文本数据，但如果后端推送的是二进制（如 Protobuf、压缩 JSON、图像帧），而前端没设置 ws.binaryType = 'arraybuffer'，就会收到乱码或解析失败的 DOMString，甚至触发 onerror。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 明确和后端约定传输格式：纯文本用
'blob'或默认；二进制必须设为'arraybuffer' - 在
new WebSocket(url)后立即设置：ws.binaryType = 'arraybuffer';
- 接收时根据
event.data类型做分支处理：typeof event.data === 'string'或event.data instanceof ArrayBuffer
如何安全重连？别直接 ws.close() 后立刻 new WebSocket()
网络抖动或服务重启时，若检测到 onclose 就立刻新建连接，容易触发浏览器连接频率限制，或陷入“连上→断开→狂连”死循环。原生 WebSocket 不自带重连逻辑，必须手动控制节奏和状态。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 用布尔变量（如
isConnecting）标记当前是否正在建连，避免并发多次new WebSocket - 采用指数退避：首次延时 1s，失败后 2s、4s、8s…最大不超过 30s
- 在
onclose中检查event.code：1006（异常关闭）、1001（服务下线）才触发重连；1000（主动关闭）则跳过
实时取数时频繁触发渲染卡顿？用 requestIdleCallback 或节流处理 onmessage
如果后端每秒推送几十条数据（比如行情、传感器流），而每次 onmessage 都直接更新 DOM 或触发 React setState，UI 线程会严重阻塞。这不是 WebSocket 的问题，而是前端消费方式不合理。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 对高频消息做客户端节流：用
setTimeout或requestIdleCallback批量合并处理 - 优先使用
requestIdleCallback（兼容性需查，可降级为setTimeout(..., 0)）：
let pendingMessages = [];
ws.onmessage = (event) => {
pendingMessages.push(event.data);
if (!isProcessing) {
isProcessing = true;
requestIdleCallback(processBatch);
}
};
function processBatch() {
// 处理 pendingMessages，更新视图
pendingMessages = [];
isProcessing = false;
}
关键点在于：WebSocket 只负责“通路”，数据怎么拿、怎么存、怎么刷屏，全由你控制节奏——最容易被忽略的，恰恰是忘了它根本不该直接驱动 UI 更新。
