原生 WebSocket 无法直接 await，因其无请求-响应语义；需手动实现请求标识、响应匹配与超时控制三层逻辑，包括生成唯一 uuid、用 Map 存储 Promise 回调、服务端返回对应 uuid，以及连接异常时清理 pending 请求。
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，未命中就丢弃（或打日志）。
WebSocket 8.18.2
下载
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 不要用
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() 就会变成定时炸弹。 
