💓 博客主页：瑕疵的CSDN主页

📝 Gitee主页：瑕疵的gitee主页

⏩ 文章专栏：《热点资讯》

Web Workers 计算不优化？页面卡到爆，别慌！

凌晨三点，用户甩来截图：页面卡成PPT。
我打开DevTools，CPU 100% 稳如老狗。
看代码：

// 问题代码：疯狂发消息constworker=newWorker('calc.js');worker.onmessage=(e)=>{// 每次计算结果都发回来updateUI(e.data);};// calc.jsself.onmessage=(e)=>{constresult=heavyCalc(e.data);// 10万次计算self.postMessage(result);// 每次都发};

用户一点击按钮，worker 就像喷泉一样狂发消息。
主线程被消息队列塞爆，页面直接死机。

核心根源：Web Workers 通信是“消息传递”，不是“共享内存”。
每次postMessage都要序列化/反序列化。
实测：1000个数据点，原版通信耗时 500ms+。
优化前：主线程卡成雕像。
优化后：主线程流畅如丝。

优化方案：减少通信次数，攒数据发。

// 优化后：批量处理constworker=newWorker('calc.js');worker.onmessage=(e)=>{updateUI(e.data);// 一次发完};// calc.jsself.onmessage=(e)=>{// 批量计算，避免多次发constresults=[];for(leti=0;i<e.data.length;i++){results.push(heavyCalc(e.data[i]));// 计算1000次}self.postMessage(results);// 只发1次};

对比：

• 原版：1000次计算 → 1000次postMessage→ 500ms
• 优化版：1000次计算 → 1次postMessage→ 50ms

实测：页面从卡顿到流畅，CPU 从 100% 降到 20%。

避坑总结：

1. 别在循环里发消息。攒数据，一次发。血泪教训，别问。
2. 避免传大对象。用ArrayBuffer或结构化克隆。传10万条数据，对象序列化比数组慢3倍。
3. 计算前先看数据量。100条以内，直接主线程算。Web Workers 有启动开销，小任务反而更慢。
4. 测试时用 Chrome Performance 面板。看主线程是否被消息队列拖死。

最后吐槽：Web Workers 不是银弹。
我昨天改完，用户说：“这下顺溜了。”
真香。
别再让 Worker 成为页面卡顿的元凶了。
（写完代码，点个咖啡，继续熬。）