Web Workers 是浏览器提供的真正多线程机制，通过独立执行上下文实现后台任务运行，避免阻塞主线程；适用于密集计算、图像处理、大数据解析等场景，需用 postMessage 通信且不可访问 DOM。

Web Workers 是浏览器提供的、让 JavaScript 在后台线程中运行的机制，它不阻塞主线程，真正实现了 Web 端的多线程编程。 它不是“模拟”多线程，而是由浏览器内核分配独立的执行上下文（含独立的全局对象、事件循环和堆内存），与主线程完全隔离——这意味着你不能直接访问 document、window 或 DOM 节点，但能自由执行耗时计算、数据处理或轮询等任务。

为什么需要 Web Workers

JavaScript 本身是单线程的，所有代码默认在主线程执行。一旦遇到密集计算（如图像处理、加密解密、大数据排序）、长循环或同步 I/O 模拟，就会卡住页面：按钮点不动、动画掉帧、滚动卡顿。Web Workers 把这些重活挪到后台线程，主线程专注渲染和交互，用户体验立刻变顺滑。

常见适用场景包括：

• 大数组排序或搜索（比如 10 万条商品数据实时筛选）
• Canvas 图像滤镜处理（高斯模糊、边缘检测）
• JSON 解析/序列化超大对象（避免主线程 freeze）
• 离线数据预处理（如本地 CSV 解析 + 聚合）
• WebAssembly 模块调用（常配合 Worker 使用）

如何创建和使用普通 Worker

分三步：写一个单独的 JS 文件作为工作线程逻辑 → 在主线程中实例化 Worker → 通过 postMessage 和 onmessage 双向通信。

例如，新建 sum-worker.js：

self.onmessage = function(e) {
  const { numbers } = e.data;
  const result = numbers.reduce((a, b) => a + b, 0);
  self.postMessage({ sum: result });
};

主线程中调用：

const worker = new Worker('sum-worker.js');

worker.onmessage = function(e) {
  console.log('计算结果：', e.data.sum); // → 55
};

worker.onerror = function(e) {
  console.error('Worker 执行出错：', e.message);
};

worker.postMessage({ numbers: [1, 2, 3, 4, 5, 6, 7, 8, 9, 10] });

注意：self 在 Worker 内指向当前 Worker 全局对象（类似主线程的 window），postMessage 发送的数据会自动结构化克隆（支持 JSON 安全类型，不支持函数、DOM 节点、undefined）。

更现代的选择：模块化 Worker 和 SharedArrayBuffer

现代浏览器支持模块化 Worker，可直接 import ES 模块：

const worker = new Worker('worker.js', { type: 'module' });

在 worker.js 中就能写 import { heavyTask } from './utils.mjs';，无需打包工具额外配置。

若需主线程与 Worker 高频共享数据（如实时音视频处理），可用 SharedArrayBuffer + Atomics 实现真正的内存共享（需开启跨域策略 crossorigin，且服务端返回 Cross-Origin-Embedder-Policy: require-corp）。不过多数业务场景用 postMessage 已足够，更安全也更简单。

注意事项和避坑点

• Worker 无法访问 DOM、localStorage、document.cookie 等主线程专属 API
• Worker 中的 console.log 输出显示在浏览器 DevTools 的 “Workers” 标签页，不是默认 Console
• 不要在 Worker 里频繁 postMessage 小数据（有序列化开销），可批量发送或改用 Transferable 对象（如 ArrayBuffer）零拷贝传输
• 记得调用 worker.terminate() 主动销毁不用的 Worker，防止内存泄漏
• Vite / Webpack 等构建工具对 Worker 路径解析可能不同，推荐用 new URL('./xxx.js', import.meta.url) 构造绝对路径

基本上就这些。Web Workers 不复杂，但容易忽略通信模型和生命周期管理。用对了，就是前端性能优化最直接的一招。