核心目标是将WebSocket的“收”与“算”分离：WebSocket负责稳定收发，Web Workers处理解析、校验、转换等耗时计算，主线程仅更新UI；这是高频消息下避免卡顿的必要设计，而非可选优化。
WebSocket 与 Web Workers 结合，核心目标是把实时通信的“收”和“算”彻底分开：WebSocket 负责稳定收发数据，Web Workers 负责后台解析、校验、转换等耗时计算，主线程只管更新界面。这不是锦上添花的优化，而是高频消息场景下避免 UI 卡顿的必要设计。
为什么必须拆到 Worker 里处理？
主线程一旦被 WebSocket 的 onmessage 回调“占住”，就无法响应用户操作或渲染帧。哪怕单条消息处理仅需 5–10ms，每秒 50 条消息就会持续占用主线程 250–500ms，页面立刻掉帧、按钮点击延迟、滚动卡顿。而 Web Worker 运行在独立线程，不抢主线程资源，也不访问 DOM，天然适合纯数据处理任务。
Worker 脚本怎么写才合规？
Worker 必须是独立的 .js 文件（如 ws-worker.js），不能内联或动态生成。它不能使用 document、window、localStorage 等 API，但支持 fetch、setTimeout、structuredClone 和 postMessage。常见错误包括：
- 在 worker 中调用
document.getElementById()→ 报ReferenceError - 直接复用主线程的工具函数（如日期格式化）→ 需重复定义，或用
importScripts('utils.js')加载（路径相对 worker 文件） - 传函数、Promise 或 undefined 给 worker → structured clone 会丢弃，导致数据丢失
主线程与 Worker 如何精准匹配消息？
WebSocket 是流式推送，Worker 处理速度可能滞后，若不加标识，结果返回后根本分不清对应哪条原始消息。必须引入唯一 ID 机制：
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 主线程发消息时带上自增 ID：
worker.postMessage({ id: ++msgId, payload: event.data }) - Worker 处理完原样返回：
self.postMessage({ id, result: processedData }) - 主线程用
Map缓存回调：callbacks.set(id, () => updateUI(data))，收到响应后查表触发
漏掉 ID 的后果很实际：股价刷新错乱、聊天消息覆盖、状态显示旧数据。
Worker 实例该不该反复新建？
每次收到消息都 new Worker('ws-worker.js') 是严重反模式。每个 Worker 启动要初始化 V8 实例，内存占用高、启动慢，还可能触发浏览器并发限制（Chrome 同源 Worker 数有隐性上限）。正确做法是：
- 全局复用一个 Worker 实例，初始化一次即可
- Worker 内部保持轻量状态，避免累积内存泄漏
- 如需多任务并行，可考虑用
SharedWorker或多个 Dedicated Worker 按业务域划分，而非按消息频次创建
不复杂但容易忽略。
