Web Worker仅对计算型长任务有效，不能加速DOM操作或网络请求；适合图像处理、加密等CPU密集任务，50ms以上才值得抽离；需用transferable避免内存翻倍；路径和调试需注意独立上下文；移动端内存受限需主动降级和清理。
Web Worker 确实能缓解卡顿，但只对计算型长任务有效
它不能加速 DOM 操作、不能减少重排重绘、也不能让 fetch 请求本身变快。卡顿是否改善，取决于你把什么逻辑塞进了 Worker。如果主线程还在频繁操作 document 或触发 resize/scroll 回调，Worker 再多也白搭。
常见误用场景包括：在 Worker 里调用 console.log（部分浏览器会同步阻塞）、试图访问 window 或 document（直接报 ReferenceError: window is not defined）、或者把轻量级数据转换（比如 JSON.parse 一个 2KB 字符串）也扔进去——通信开销反而比执行还贵。
- 适合放进 Worker 的：图像像素处理、加密解密、大数组排序、路径规划、离线文本分词
- 不适合的：
element.classList.add()、requestAnimationFrame调度、localStorage读写（除非配合 IndexedDB 批量导出） - 性能拐点参考：纯 CPU 计算耗时 ≥ 50ms，才值得抽离；否则建议用
setTimeout分片或queueMicrotask
主线程和 Worker 通信不是免费的，要小心序列化陷阱
postMessage 传递数据时，默认走结构化克隆算法（structured clone），这意味着 Date、RegExp、Map、Set 都能传，但 function、undefined、canvas、blob（未启用 transferable）会丢或报错。更隐蔽的问题是：传一个 10MB 的 ArrayBuffer，如果不加 transfer，主线程和 Worker 会各自持有一份副本，内存翻倍。
正确做法是用 transferable 选项移交所有权：
立即学习“前端免费学习笔记（深入）”；
worker.postMessage(data, [data.buffer]); // data 是 Float32Array
漏掉这个，大数据量下容易触发内存告警甚至页面崩溃，尤其在低端 Android 设备上。
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
- 传对象前先
JSON.stringify再JSON.parse？别——这是在主动放弃transferable和二进制支持 -
onmessage回调里不做深拷贝，直接复用传入的ArrayBuffer视图（如new Uint8Array(e.data)） - 避免高频通信：不要在
mousemove里每帧postMessage，改用节流 + 批量打包
调试 Web Worker 卡在“没反应”？先检查作用域和加载路径
Worker 脚本是在独立上下文执行的，不继承主线程的 base URL，也不走 webpack/vite 的模块解析逻辑。常见错误是：new Worker('./utils/worker.js') 在 SPA 路由下 404，因为实际请求路径是 https://site.com/some/route/utils/worker.js，而非项目根目录。
解决方案优先级：
- 用绝对路径：
new Worker('/workers/calc.js')（确保该路径可被静态服务器直出） - Vite 用户加
?url后缀：new Worker(new URL('./calc.worker.js', import.meta.url)) - Webpack 用户配
new WorkerPlugin()并用new Worker(new URL('./calc.js', import.meta.url)) - Chrome DevTools 中 Worker 不显示在 Sources → Page，而是在 Sources → Workers 标签页，且断点需手动启用
另外，Worker 内部抛出未捕获异常不会冒泡到主线程 window.onerror，必须监听 worker.onerror 或在 Worker 内写 self.addEventListener('error', ...)。
移动端兼容性看似够用，但内存限制比桌面严得多
虽然 Chrome/Firefox/Safari（iOS 16.4+）都支持 Web Worker，但 iOS Safari 对 Worker 的内存分配有硬限制（约 128MB），超出后整个 Worker 进程会被静默终止，且不触发 worker.onmessage 或 worker.onerror。Android WebView 表现更不稳定，某些厂商定制系统会限制 Worker 创建数量（如最多 4 个）。
应对策略不是“不用”，而是“可控”：
- 创建前先检查：
if (typeof Worker !== 'undefined')，但别仅靠这个——iOS 15.6 之前虽支持 Worker，却禁用SharedArrayBuffer，影响高性能场景 - Worker 初始化失败时降级到主线程分片执行（用
setTimeout切成 5ms 小块） - 避免长期驻留 Worker：计算完立刻
self.close()，尤其在单页应用路由切换时显式worker.terminate()
真正容易被忽略的，是「Worker 生命周期与页面生命周期不同步」——用户切到后台标签页，主线程可能被冻结，但 Worker 仍在跑，继续吃内存、发日志、甚至触发 fetch（如果没加 abort 控制）。这种隐性资源泄漏，在低端设备上几小时就能拖垮整个浏览器进程。
