17370845950

WebSocket是JavaScript实时通信唯一标准方案；连接失败主因是环境或服务端配置，如协议不匹配（wss需HTTPS）、端口错误、Origin校验缺失、代理未透传Upgrade头；onmessage需先判data类型再JSON解析；close事件中reason/code仅服务端主动关闭时可靠，异常断连恒为1006；核心难点在重连、消息队列、心跳等自实现逻辑。

WebSocket 是 JavaScript 实现实时通信的唯一标准方案，其他如轮询、SSE 都是妥协或补充手段。

WebSocket 连接失败的常见原因和检查点

连接不上不是代码写错了，大概率是环境或服务端配置问题：

• ws:// 协议不能在 https:// 页面中使用，必须用 wss://（否则浏览器直接拒绝）
• 服务端没启动或监听地址不对，比如前端连 ws://localhost:8080，但后端实际跑在 3000 端口
• 跨域不是 WebSocket 的问题——它本身不受同源策略限制，但服务端必须明确允许该 Origin（比如 Express + ws 库需手动校验 req.headers.origin）
• 代理或 Nginx 没开启 WebSocket 支持：Upgrade 和 Connection 头被过滤会导致握手 400

如何正确处理 onmessage 中的 JSON 数据

服务端发来的消息不一定是字符串，也可能是 ArrayBuffer（尤其传输二进制时），直接 JSON.parse() 会报错：

• 先判断 event.data 类型：typeof event.data === 'string' 再解析
• 如果服务端明确约定只发 JSON 字符串，可在连接建立后加一层封装：

  socket.onmessage = (e) => {
    if (typeof e.data === 'string') {
      try {
        const msg = JSON.parse(e.data);
        // 处理业务逻辑
      } catch (err) {
        console.warn('Invalid JSON:', e.data);
      }
    }
  };

• 避免在 onmessage 里做重解析或深层嵌套转换，容易阻塞主线程；复杂结构建议用 ArrayBuffer + TextDecoder 或 JSON.parse 后立刻交由 Web Worker

为什么 close 事件里拿不到服务端传来的 reason 和 code

close 事件的 event.code 和 event.reason 只有服务端主动调用 close(code, reason) 并且 code 在 3000–4999 范围内

时才可靠传递。浏览器发起的断连（如网络中断、页面关闭）只会返回默认 code=1006，reason 为空字符串。

• 不要依赖 event.reason 做错误分类，应结合 event.code 和连接状态（如 socket.readyState !== WebSocket.OPEN）做降级处理
• 需要传递上下文信息，应在断开前主动发一条 type: "disconnect" 的控制消息，而不是等 close 事件
• 1000 表示正常关闭，1001 是服务端/客户端主动离开（如页面卸载），1006 是异常关闭（无法恢复），这些 code 是标准化的，可查 IANA 注册表

真正难的不是建立连接，而是断线重连策略、消息队列暂存、重复投递识别、心跳保活节奏——这些不在 WebSocket API 里，得自己补全。