WebSocket消息回调封装，实现类似Promise调用

原生 WebSocket 缺乏请求-响应语义，无法直接 await，但通过手动封装「唯一请求标识（uuid）+ 响应精准匹配 + 超时与异常兜底」三层逻辑，就能实现如 `await wsRequest(...)` 般简洁可靠的异步调用体验——关键在于每条消息可追溯、每条响应可归属、每次断连可清理，否则看似优雅的 Promise 封装实则暗藏悬停、泄漏与乱序等致命风险。

WebSocket 本身不带请求-响应语义，直接调用 send() 后无法知道哪条消息对应哪个响应——这不是 bug，是协议设计使然。要实现类似 await wsRequest(...) 的体验，必须自己补上「请求标识 + 响应匹配 + 超时控制」这三层逻辑。

为什么原生 WebSocket 不能直接 await

原生 WebSocket 是事件驱动模型：onmessage 是全局监听器，所有响应都进同一个入口；没有内置的 request-id 绑定机制，也没有失败重试或超时取消能力。你发 5 条消息，收到 3 条回复，根本没法确定哪条回复属于哪次调用。

sendMessage() 必须返回 Promise 并注入唯一 uuid

关键不是“封装 send”，而是让每次发送都可追溯。核心动作有三步：

• 生成唯一 uuid（推荐用 crypto.randomUUID() 或 self.crypto.randomUUID()，避免第三方库）
• 把 resolve/reject 存进一个 Map，key 是该 uuid，value 是 { resolve, reject, timeoutId }
• 在 send() 前把 uuid 塞进消息体，比如 { uuid: 'xxx', type: 'query', data: {...} }

示例片段：

const pendingMap = new Map();

function sendMessage(data) {
  const uuid = crypto.randomUUID();
  const message = { ...data, uuid };

  return new Promise((resolve, reject) => {
    const timeoutId = setTimeout(() => {
      pendingMap.delete(uuid);
      reject(new Error(`timeout: ${uuid}`));
    }, 10000);

    pendingMap.set(uuid, { resolve, reject, timeoutId });
    socket.send(JSON.stringify(message));
  });
}

onmessage 中必须按 uuid 分发响应

服务端返回的消息体里，必须包含与请求一致的 uuid 字段（否则整个机制失效）。客户端收到后，只做一件事：查 pendingMap，命中就 resolve 或 reject，未命中就丢弃（或打日志）。

• 不要用 event.data 直接解析后全局广播——那会破坏 Promise 的一对一契约
• 如果服务端不返 uuid，必须推动后端改；前端强行伪造会导致乱序、重复 resolve 等不可控问题
• 建议服务端响应结构统一为 { uuid: string, code: number, data?: any, msg?: string }

处理逻辑示例：

socket.onmessage = (event) => {
  let res;
  try {
    res = JSON.parse(event.data);
  } catch (e) {
    console.warn('invalid ws message', event.data);
    return;
  }

  const handler = pendingMap.get(res.uuid);
  if (!handler) return;

  pendingMap.delete(res.uuid);
  clearTimeout(handler.timeoutId);

  if (res.code === 0) {
    handler.resolve(res.data);
  } else {
    handler.reject(new Error(res.msg || `code ${res.code}`));
  }
};

连接状态和重连会破坏 pending 请求，必须主动清理

WebSocket 断开时，所有未响应的 Promise 都会悬停（既不 resolve 也不 reject），变成内存泄漏+逻辑卡死。这是最容易被忽略的点。

• 在 onclose 和 onerror 中遍历 pendingMap.values()，对每个 reject 掉并清空 Map
• 重连成功后，不能复用旧的 pendingMap——新连接下旧 uuid 已无效，必须新建 Map
• 如果业务允许，可在重连后对部分关键请求自动重发（需服务端幂等支持）

简单清理示例：

socket.onclose = socket.onerror = () => {
  for (const { reject } of pendingMap.values()) {
    reject(new Error('ws disconnected'));
  }
  pendingMap.clear();
};

实际跑通的关键不在语法多炫，而在于「每条发出的消息是否可定位、每条收到的响应是否可归属、每次连接异常是否可兜底」。漏掉任意一环，await wsRequest() 就会变成定时炸弹。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于文章的相关知识，也可关注golang学习网公众号。