WebSocket高频消息导致UI卡顿的根源是主线程承担了过多计算任务，必须将JSON解析、校验、转换等纯计算逻辑移至Web Worker处理，主线程仅负责收发与DOM更新。
WebSocket消息一多，UI就卡——问题不在连接本身，而在你把解析、校验、转换这些活儿全塞给了主线程。Web Workers不是“锦上添花”，而是处理高频/高负载WebSocket数据时的必选项。
WebSocket.onmessage里别干重活
直接在 onmessage 回调里做 JSON 解析、正则匹配、嵌套对象深拷贝、时间格式化，等于让浏览器渲染线程排队等你算完。哪怕单条消息处理只耗 8ms，100 条/秒就是 800ms 连续占满主线程，页面必然掉帧甚至假死。
- 把所有非 DOM 操作的纯计算逻辑（比如
validateMessage()、transformPayload()）全部移出主线程 - 保留主线程只做三件事：接收原始
event.data、发给 Worker、收到结果后更新 state 或 DOM - 避免在主线程里对
event.data做JSON.parse()后立刻遍历——Worker 可以接字符串，自己 parse，也更可控
Worker 脚本必须独立文件，且不能访问 DOM
Web Worker 的脚本必须是一个单独的 .js 文件，不能是内联函数或字符串 eval。它没有 document、window、localStorage，但能用 fetch、setTimeout、structuredClone（需支持）和 postMessage。
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 不要试图在
worker.js里写document.getElementById()——会报ReferenceError: document is not defined - 如果需要共享工具函数（如日期格式化），要么重复定义，要么用
importScripts()加载公共库（注意路径是相对 worker 文件的） - 传给 Worker 的数据会被结构化克隆（structured clone），包含
Date、RegExp、ArrayBuffer等，但不支持函数、undefined、Promise
主线程与 Worker 通信要带唯一 ID 防混淆
WebSocket 是持续流式推送，Worker 处理速度可能跟不上接收速度。若多个消息并发进入 Worker，又都用 self.postMessage() 返回，主线程无法分辨哪条结果对应哪条原始消息。
- 主线程发消息时带上自增
id：worker.postMessage({ id: ++msgId, payload: rawMsg }) - Worker 收到后原样返回：
self.postMessage({ id, result: processed }) - 主线程用
Map缓存待响应的回调：callbacks.set(id, callback)，收到结果后查表触发 - 不加 ID 的后果：UI 更新错乱、状态覆盖、用户看到“上一秒的股价”覆盖了“当前价”
Worker 实例建议复用，别每次 new
频繁创建销毁 Worker（比如每条消息都 new Worker('ws-worker.js')）开销远超预期：每个 Worker 占用独立 V8 实例，内存上升快，启动延迟明显，还可能触发浏览器限制（Chrome 对同源 Worker 数量有限制）。
- 全局只持有一个
const wsWorker = new Worker('ws-worker.js') - Worker 内部用队列 + 循环处理（
while (queue.length) {...}）或直接同步处理单条，避免堆积 - 必要时可加简单节流：Worker 收到消息后用
setTimeout延迟 0ms 排队，防止压垮自身事件循环 - 极端场景（如瞬时 500 条/秒）可考虑两个 Worker 轮询分担，但优先优化单个 Worker 的处理效率
最常被忽略的一点：Worker 里抛出未捕获异常不会打印到主线程控制台，而是静默失败。务必在 self.onmessage 内包 try/catch，并主动 self.postMessage({ type: 'error', id, message }) ——否则你会以为消息“丢了”，其实是在 Worker 里崩了。
