前端 Web Worker 使用场景

Web Worker 的核心价值只有一个：把单次执行超过 16ms 的同步 JavaScript 计算从主线程搬到后台线程，让页面不卡。结论是——凡是「计算密集、纯 JS、不需要碰 DOM」的任务都该用 Worker；而 IO 等待、DOM 操作、几毫秒就能跑完的逻辑，用 Worker 反而更慢（创建 Worker 本身就要 1~20ms，通信还有序列化开销）。

Web Worker 到底解决什么问题？

结论：它解决的是主线程被长任务占满导致的掉帧和输入延迟。浏览器里 JS 执行、样式计算、布局、绘制都跑在主线程，一帧只有 16.7ms（60fps）。主线程里出现一个 200ms 的同步循环，这一帧就必然丢，用户感觉是「点了没反应」。

Web Worker 是浏览器提供的独立线程，和主线程并行执行，互不阻塞。它不能访问 document、window、parent，但能访问 fetch、XMLHttpRequest、WebSocket、IndexedDB、crypto、setTimeout、WebAssembly。

判断标准很硬：用 Performance 面板看，如果某个任务的自我耗时（Self Time）超过 50ms，就该考虑搬走。

哪些场景最适合用 Web Worker？

结论：前端加解密、大文件哈希、图像/视频处理、大数据量聚合计算、代码高亮与解析这五类是收益最明显的场景。

1. 大文件分片哈希（做秒传/断点续传）：对一个 2GB 文件算 MD5，主线程同步算几十秒必卡死；在 Worker 里配合 crypto.subtle.digest 或 spark-md5 分片计算，页面完全流畅。
2. 前端加解密：AES/RSA 处理大文本时，crypto.subtle 是异步 API，但配套的编码转换、分块拼接是同步计算，放 Worker 里更稳。
3. 图像/视频处理：像素级滤镜、亮度对比度调整、Canvas 数据批量处理。配合 OffscreenCanvas，用 canvas.transferControlToOffscreen() 把画布控制权交给 Worker，渲染也在子线程完成。
4. 大数据量计算：10 万行表格的前端排序、筛选、透视，或 ECharts 需要的前置数据聚合。
5. 语法解析：Markdown 渲染、代码高亮（highlight.js）、AST 解析、公式计算引擎。

Web Worker 怎么传数据才不卡？

结论：大数据用 Transferable Objects 零拷贝转移，小数据批量合并后再发，永远不要在主线程里循环 postMessage 一条条发。

默认的 postMessage 走结构化克隆，会把对象完整复制一份。传一个 50MB 的 ArrayBuffer，主线程要花时间序列化，等于把卡顿转移了地方。

正确做法是把 ArrayBuffer、MessagePort、OffscreenCanvas、ImageBitmap 作为可转移对象传，写法是在第二个参数里列出：

// 主线程：所有权转移，零拷贝，转移后主线程该 buffer 变为不可用
worker.postMessage({ buffer }, [buffer]);

注意：转移后原线程的 ArrayBuffer 长度变成 0，不能再读写。另外始终用 { type: 'xxx', payload: {} } 的对象消息格式，方便后续扩展多任务分发。

Web Worker 有哪些坑不能踩？

结论：三条硬约束——不能碰 DOM、路径和跨域受限制、加载 TypeScript/模块需要额外配置。

• 不能操作 DOM，也不支持 alert、localStorage（IndexedDB 和 Cache 可用）。DOM 操作只能回到主线程用消息驱动。
• 同源限制：Worker 脚本必须同源，用 new Worker('https://cdn.other.com/w.js') 会直接报错。跨域脚本只能靠 importScripts() 加载。
• 模块化写法：用 ES Module 要加 type: 'module'（Chrome 80+ 支持）。Vite 里写成 new Worker(new URL('./hash.worker.js', import.meta.url), { type: 'module' })，Webpack 5 也识别 new URL(...) 语法自动打包，不能直接写变量路径。

Worker 池什么时候必须上？

结论：任务数量超过 4 个、或需要反复创建销毁时，用 Worker 池复用线程，池大小取 navigator.hardwareConcurrency（通常 4~16）。

每次 new Worker() 都要重新加载脚本、初始化运行时，实测开销 1~20ms。如果你要处理 100 张图片，逐个创建 Worker 的开销比计算本身还大。

池的思路：启动时创建 N 个 Worker 常驻，用任务队列派发，每个 Worker 处理完发回 { type: 'done' } 再取下一个任务。N 不要超过 navigator.hardwareConcurrency，超过只会增加线程切换成本，不会更快。

最后提醒一句：Worker 不是银弹。小于 10ms 的计算放进去，通信开销比计算还大；纯 fetch 请求本来就是异步的，搬进 Worker 没有任何收益。先量出主线程的长任务，再决定搬什么进去。