17370845950

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);
  }
};
funct
ion processBatch() {
  // 处理 pendingMessages，更新视图
  pendingMessages = [];
  isProcessing = false;
}

关键点在于：WebSocket 只负责“通路”，数据怎么拿、怎么存、怎么刷屏，全由你控制节奏——最容易被忽略的，恰恰是忘了它根本不该直接驱动 UI 更新。