17370845950

WebSocket连接后立即send失败因状态延迟，需safeSend校验readyState；心跳需应用层实现ping/pong；onmessage应try-catch、防阻塞、区分数据类型；重连须指数退避并清理旧连接。

WebSocket 连接建立后立即收发消息失败？

常见现象是 onopen 触发了，但紧接着 send() 报错 InvalidStateError: Failed to execute 'send' on 'WebSocket': Still in CONNECTING state。这是因为连接状态切换有微小延迟，onopen 回调虽已触发，底层握手未必完全就绪。

• 稳妥做法：在 onopen 回调里用 setTimeout(() => ws.send(...), 0) 或直接用 ws.readyState === WebSocket.OPEN 双重校验
• 更推荐封装一个 safeSend() 方法，内部轮询或 Promise 化等待就绪
• 不要依赖 onopen 后立刻发包——浏览器实现和网络抖动会让这个“立刻”不可靠

如何处理心跳与自动重连？

WebSocket 没有内置心跳机制，服务端通常会在空闲 30–60 秒后关闭连接。客户端不主动探测，就会静默断开，且 onclose 不一定及时触发。

• 服务端若支持 Ping/Pong 帧，浏览器会自动响应，但多数 Node.js/Python 后端需手动实现；更通用的做法是应用层心跳
• 定时用 ws.send(JSON.stringify({ type: 'ping' }))，并监听对应 pong 响应（服务端返回 { type: 'pong' }）
• 重连逻辑必须限制次数和间隔，例如指数退避：1s → 2s → 4s → 8s，超过 5 次失败后暂停或提示用户
• 重连前要清除旧定时器、置空 ws 引用，否则可能产生多个并发连接

接收消息时如何区分业务类型并避免阻塞主线程？

onmessage 是同步回调，如果解析大 JSON 或执行复杂逻辑，会卡住 UI。同时，服务端可能批量推送、乱序到达，纯靠 JSON.parse() 容易崩溃。

• 始终用 try...catch 包裹 JSON.parse()，并记录原始 event.data 便于排查
• 对高频消息（如实时位置、传感器数据），考虑用 requestIdleCallback() 或 setTimeout(..., 0) 延迟处理，让出主线程
• 用 event.data instanceof Blob 判断是否为二进制数据，避免误转字符串；必要时用 new FileReader().readAsText()
• 不要在 onmessage 里直接更新大量 DOM，优先写入内存缓存，再节流渲染

const ws = new WebSocket('wss://api.example.com');
ws.onmessage = (event) => {
  try {
    const data = typeof event.data === 'string' 
      ? JSON.parse(event.data) 
      : event.data;
    if (data.type === 'chat') {
      handleChat(data.payload);
    } else if (data.type === 'ping') {
      ws.send(JSON.stringify({ type: 'pong' }));
    }
  } catch (e) {
    console.error('Invalid message:', event.data, e);
  }
};

WebSocket 的真实难点不在连接本身，而在连接之后的状态同步、错误恢复和消息生命周期管理——尤其是重连时未发完的消息如何暂存、重复投递怎么去重、离线期间的本地操作如何合并。这些没法靠一个 new WebSocket() 解决。