主线程处理100+条/秒WebSocket消息会卡死，因为每条onmessage回调均在主线程执行，高频JSON解析、状态更新与DOM操作挤占60fps渲染时间，导致requestAnimationFrame无法及时执行、UI冻结；Web Worker必须接管解析、过滤、聚合三类纯计算任务，不可触碰DOM、console或WebSocket实例，通信需用MessageChannel与Transferable对象，并严格对齐其生命周期与连接状态。
为什么主线程处理100+条/秒WebSocket消息会卡死
因为每条onmessage回调都默认在主线程执行，而高频解析、状态更新、DOM操作会直接挤占渲染帧时间。Chrome的60fps刷新节奏被强行打断，requestAnimationFrame来不及执行，UI就“冻住”了。这不是WebSocket协议的问题，是前端把数据流和渲染线程绑太紧。
Web Worker必须接管哪些WebSocket任务
Worker不是万能分流器，只该干三类事：解析（JSON.parse或二进制解包）、过滤（剔除无效消息）、聚合（按秒/按类型合并数据）。其他事别让它碰：
- 不要在Worker里调用
postMessage传原始大数组——改用Transferable对象（如ArrayBuffer）零拷贝传递 - 不要在Worker里做任何DOM操作或调用
console.log（会序列化阻塞） - 不要让Worker持有对主线程
WebSocket实例的引用——连接管理必须留在主线程
主线程与Worker通信的关键细节
高频场景下，postMessage本身会成为瓶颈。必须遵守这几条：
前端设计优化skill
下载
前端设计与 UI/UX 全方位优化专家。覆盖视觉层次、排版系统、色彩理论、响应式布局、交互体验、动画动效、无障碍访问、性能优化八大维度，帮助开发者将普通页面升级为高品质产品级界面。前端设计与 UI/UX 全方位优化专家。覆盖视觉层次、排版系统、色彩理论、响应式布局、交互体验、动画动效、无障碍访问、性能优化八大维度，帮助开发者将普通页面升级为高品质产品级界面。
- 用
MessageChannel替代单向postMessage，避免主线程消息队列积压 - Worker内部用
setInterval批量读取缓冲区，而不是每来一条就postMessage一次 - 主线程接收时用
useCallback（React）或shallowRef（Vue3）缓存处理函数，防止闭包导致内存泄漏 - Worker脚本必须用
importScripts加载依赖，不能用ESMimport——Chrome 112+才支持Worker内原生ESM
容易被忽略的Worker生命周期陷阱
Worker不是启动了就一直活着。Chrome会在标签页后台化后冻结Worker，5分钟无活动就销毁它。这意味着：
立即学习“前端免费学习笔记（深入）”；
- 不能把未确认的消息ID存在Worker内存里——要同步到主线程的
Map或IndexedDB - Worker重启时，主线程必须重新发送当前订阅参数（如
{ channel: "stocks" }），否则它不知道该处理什么 - 用
worker.terminate()前，务必先worker.postMessage({ type: "flush" })清空缓冲区，否则最后几条消息会丢失
真正的难点不在启动Worker，而在让它的生命周期和WebSocket连接状态严格对齐——这需要你在重连、切换频道、页面卸载时都手动同步状态。
