主线程卡死的典型表现是按钮点不动、滚动条拖不了、requestAnimationFrame停摆、开发者工具打不开；Web Workers通过独立线程执行CPU密集型任务并用postMessage通信来规避此问题。
JavaScript 是单线程的，主线程一旦被耗时操作阻塞（比如大数组排序、图像处理、复杂计算），整个页面就会卡住——用户点击无响应、动画掉帧、输入延迟。Web Workers 就是用来把这类任务搬出主线程的唯一标准方案。
主线程卡死的典型表现是什么
你写了个 for 循环处理 10 万条数据，或调用 JSON.parse() 解析几 MB 的 JSON 字符串，浏览器就“假死”了：按钮点不动、滚动条拖不了、requestAnimationFrame 停摆、甚至开发者工具都打不开。这不是代码写错了，是 JavaScript 引擎天然限制——它只给一个调用栈、一个事件循环。
Web Workers 怎么避开主线程限制
Worker 在独立线程里运行，有自己完整的 JavaScript 执行环境（但没有 window、document、localStorage 等 DOM 相关 API）。它和主线程靠 postMessage() 和 onmessage 通信，数据通过结构化克隆（不是共享内存）传递：
// main.js
const worker = new Worker('worker.js');
worker.postMessage({ data: bigArray });
worker.onmessage = (e) => console.log(e.data.result);
<p>// worker.js
self.onmessage = (e) => {
const result = e.data.data.map(x => x * 2);
self.postMessage({ result });
};- Worker 文件必须是同源的独立 JS 文件，不能是内联字符串或 Blob URL（除非明确用
Blob构造并URL.createObjectURL） - 传给
postMessage()的对象会被序列化，函数、undefined、Symbol、Promise会丢失 - 频繁通信反而比不拆线程更慢——适合“一次喂入、一次返回”的重计算，不适合高频小数据交互
哪些场景真该用 Web Workers
不是所有异步操作都需要 Worker。以下情况才值得引入：
Comprehensive Three.js 3D graphics reference
下载
详细的 Three.js 3D 图形参考，涵盖场景设置、相机、几何体、材质、光照、动画、控制器、加载器、数学工具和调试。
立即学习“Java免费学习笔记（深入）”；
- 纯 CPU 密集型任务：如加密解密（
SubtleCrypto在主线程也行，但大文件加密仍建议 Worker）、音频/视频帧处理、物理模拟、大型数据聚合（Array.reduce()百万级数据） - 避免阻塞渲染的关键路径：比如在
resize或scroll中做布局分析，可先发到 Worker 计算，再用requestIdleCallback同步结果 - 需要长时间运行又不能用
setTimeout拆解的任务：比如递归深度优先搜索树、实时日志解析
别用 Worker 处理网络请求（fetch 本身异步）、DOM 操作（它根本不能访问 DOM）、或只是加个 await 的轻量逻辑——那只会增加启动开销和通信负担。
兼容性和常见陷阱
现代浏览器都支持 Web Workers（包括 Safari iOS 5.1+），但要注意：
- Worker 内不能用
alert()、console.log()（部分浏览器支持，但输出位置在 Worker 控制台，容易漏看） - Worker 中的
importScripts()不支持 ES 模块语法，要用import必须设type="module"并用new Worker('x.js', { type: 'module' }) - 调试困难：Chrome DevTools 的 Sources 面板要手动打开 “Workers” 折叠栏；断点只能打在 Worker 脚本里，不能跨线程追踪
- 内存泄漏风险更高：主线程忘了
worker.terminate()，Worker 就一直挂着；Worker 里用了闭包引用大对象，GC 也不一定及时回收
真正难的从来不是“怎么起一个 Worker”，而是判断“这个任务到底值不值得搬出去”——多数卡顿问题其实该先查 performance.mark() 定位瓶颈，而不是直接上多线程。
