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);
/ calc.js /
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 分片就能缓解。