web workers 能提升性能，但仅适用于纯计算、无 dom、可拆分的任务，如大数组排序、图像处理、加密解密等；误用于 dom 操作或轻量任务反会因通信开销降低性能。
Web Workers 在 HTML5 里真能提升性能？
能，但只在特定场景下有效。它不是“开个线程就变快”，而是把耗时的 JavaScript 计算从主线程剥离，避免阻塞页面渲染和用户交互。如果你的逻辑主要是 DOM 操作、事件响应或轻量计算，Web Workers 不仅没用，还会因通信开销拖慢整体表现。
哪些任务适合丢进 Worker？
核心判断标准：是否满足「纯计算 + 无 DOM + 可拆分」。常见适用场景包括：
- 大数组排序、滤波、加密解密（如
AES、SHA-256） - 图像处理（Canvas 像素遍历、滤镜计算）
- 解析大型 JSON 或 CSV（不依赖
DOMParser或fetch回调） - 复杂物理模拟、路径规划、机器学习推理（WebAssembly 配合更佳）
注意：Worker 无法访问 window、document、localStorage 等主线程专属 API，也不能直接操作 DOM —— 所有 UI 更新必须靠 postMessage 回传数据，由主线程接手。
主线程和 Worker 通信怎么写才不翻车？
通信是最大易错点。常见错误包括：传入函数/闭包、发送未序列化的对象、高频小数据频繁 postMessage 导致队列积压。
立即学习“前端免费学习笔记（深入）”；
正确做法：
- 只传可序列化的数据（基本类型、普通对象、
ArrayBuffer，优先用Transferable移动大数组） - 避免在循环里密集调用
postMessage，改用节流或批量合并 - Worker 内用
self.onmessage接收，主线程用worker.onmessage监听，别漏掉error事件
/* 主线程 */
const worker = new Worker('calc.js');
worker.postMessage({ type: 'SORT', data: largeArray });
worker.onmessage = (e) => {
document.getElementById('result').textContent = e.data.result;
};
worker.onerror = (e) => console.error('Worker error:', e.message);
<p>/<em> calc.js </em>/
self.onmessage = (e) => {
if (e.data.type === 'SORT') {
const result = e.data.data.sort((a, b) => a - b);
self.postMessage({ result });
}
};为什么有时用了 Worker 反而更慢？
典型原因有三个：
-
Worker启动本身有开销（约几毫秒），短任务（ - 主线程和 Worker 之间复制大数据（比如未用
Transferable的Uint8Array）触发深拷贝，内存和时间双爆炸 - 过度设计：把本可异步分片执行的逻辑硬塞进 Worker，反而增加调度复杂度
真实项目中，建议先用 performance.now() 测主线程耗时，确认瓶颈确实在 JS 执行而非网络或渲染；再评估是否值得引入 Worker。很多“卡顿”其实只需 requestIdleCallback 或 setTimeout 分片就能缓解。
