17370845950

Web Worker 是浏览器提供的独立 JS 线程，不共享主线程内存、不可访问 DOM，仅通过 postMessage 通信；适用于 CPU 密集型任务如大数据处理、图像计算、加密等，而非简单异步操作。

Web Worker 是什么：主线程的“外包员工”

Web Worker 是浏览器提供的一个独立执行 JavaScript 的线程，它**不共享主线程的内存，也不访问 DOM、window、document 等全局对象**。它就像把一段耗时逻辑“外包”出去，让主线程继续响应点击、滚动、渲染，避免卡顿。

它的本质是：一个运行在后台的、与主线程并行的 JS 执行环境，通信只能靠 postMessage() 和 onmessage——没有共享变量，只有消息传递。

什么时候该用 Web Worker：别为简单计算开线程

不是所有异步操作都适合 Worker。它启动有开销（初始化、序列化、跨线程通信），小任务反而更慢。适用场景明确：

• 大量数组/对象遍历、排序、过滤（比如处理上万条日志数据）
• 图像像素级处理（ImageData 计算、滤镜、缩放）
• 加密解密、哈希计算（如 bcrypt、SHA-256）
• 复杂物理模拟或路径规划（游戏、GIS 应用）
• 解析大型 JSON 或 CSV（尤其需校验/转换字段时）

反例：setTimeout、fetch 请求本身、简单字符串拼接——这些本就异步或开销极小，Worker 不仅无益，还会增加通信负担。

怎么写一个基础 Worker：注意路径和作用域隔离

Worker 脚本必须是独立文件（不能是内联字符串），且路径受同源策略限制。常见错误是 404 或 SecurityError，往往因为路径写错或服务未启用 CORS（对本地 file:// 协议尤其敏感）。

主线程中创建：

const worker = new Worker('./path/to/processor.js');
worker.postMessage({ data: hugeArray, action: 'sort' });
worker.onmessage = (e) => {
  console.log('结果已返回:', e.data);
};

worker 脚本（processor.js）里：

self.onmessage = function(e) {
  const { data, action } = e.data;
  let result;
  if (action === 'sort') {
    result = data.sort((a, b) => b - a); // 注意：sort 会原地修改
  }
  self.postMessage(result); // 只能传可序列化值（或 Transferable 对象）
};

关键点：

• self 是 Worker 全局对象，不是 window
• postMessage() 传参会自动结构化克隆（deep clone），大数组可能卡顿；如需零拷贝，用 Transferable（如 postMessage(data, [data.buffer])）
• 不能用 console.log 直接输出到主页面控制台，但现代浏览器支持 console（输出在 “Workers” 标签页下）

性能提升的关键不在“开线程”，而在“减少通信+合理拆分”

很多人以为只要扔进 Worker 就快了，实际瓶颈常在通信频率和数据体积。例如每帧都传 canvas 像素数据过去处理，比直接在主线程画还慢。

优化方向很实在：

• 批量处理：把 100 次小计算合并成 1 次大消息，而不是循环 100 次 postMessage
• 用 Transferable：对 ArrayBuffer、TypedArray、ImageBitmap 等，传引用而非拷贝（postMessage(data, [data.buffer])）
• 复用 Worker：用 Worker 构造函数创建新实例成本高，长任务建议 new Worker(...) 后长期持有，通过消息调度不同任务
• 避免频繁 onmessage 回调：Worker 内部可用 while(true) { self.onmessage = ... } 配合 event.waitUntil（不推荐），更稳妥是用单次监听 + 递归调用或 MessageChannel 实现多路通信

真正卡顿的页面，问题往往出在没拆分任务粒度、通信设计粗糙，或者误把 I/O 密集型操作（如读文件）塞进 Worker——它只解决 CPU 密集型阻塞，不加速网络或磁盘。