web worker 是 html5 提供的多线程解决方案，用于将耗时计算移至后台线程执行，避免阻塞主线程导致卡顿、无响应等问题，适用于大数据处理、数学密集运算、文本分析等纯逻辑任务。
当页面出现明显卡顿、点击无响应、滚动不流畅，且确认问题源于 JavaScript 计算而非网络或渲染瓶颈时，就该考虑 Web Worker 了。核心判断标准不是“有没有计算”，而是“计算是否在主线程上持续占用超过 16ms（即一帧时间）”，一旦频繁超时，用户就能感知卡顿。
哪些任务明确需要移出主线程
以下几类操作一旦在主线程执行，极易引发阻塞，应优先交给 Worker 处理：
- 大数据遍历与转换：比如解析上万条 JSON 数据、对大型数组做 map/filter/reduce、格式化时间戳列表等；单次循环若超过 5000 次且含复杂逻辑，就值得警惕。
- 数学密集型运算：图像像素处理（灰度、滤镜）、加密解密（如 AES、RSA）、路径规划、物理模拟、机器学习推理（轻量模型）等 CPU 占用高的任务。
- 文本分析类操作：全文搜索索引构建、正则批量匹配（尤其是回溯严重的正则）、语法高亮预处理、Markdown 渲染（长文档）。
- 离线数据预处理：本地文件读取后的内容解析（CSV/Excel/JSON）、缓存数据聚合、历史行为统计汇总等，尤其在 PWA 或桌面端 Web 应用中常见。
哪些情况其实不需要 Worker
误用 Worker 反而增加通信开销和内存负担，以下场景通常无需引入：
- AJAX 请求本身：fetch 或 XMLHttpRequest 原生异步，回调执行虽在主线程，但请求过程不占 CPU；只有回调里紧接着做大量计算才需拆分。
- 简单 DOM 操作：增删少量节点、修改 class 或 style，这些本就是高效操作，Worker 还无法访问 DOM，强行拆分得不偿失。
- 微小计算（：例如计算两个数的和、对象浅拷贝、短字符串拼接——这类任务即使同步执行也不会影响帧率。
- 定时器分片已够用的任务：比如用 requestIdleCallback 或 setTimeout 拆解的中等规模遍历（几千项以内），只要每帧控制在 5ms 内，Worker 并非必需。
如何快速验证是否真被主线程阻塞
别靠感觉，用浏览器开发者工具直接观测：
- 打开 Chrome DevTools → Performance 标签 → 点击录制，复现卡顿操作 → 停止后查看主线程火焰图，找连续 >16ms 的黄色（Scripting）或紫色（Rendering）长条。
- 关注 “Main” 线程的 Tasks 列表，若某 task duration 明显高于其他（如 80ms），点开看调用栈，定位具体函数。
- 配合 console.time() / console.timeEnd() 在疑似耗时函数前后打点，确认真实执行时长，避免被事件循环调度干扰判断。
上线前的关键检查点
Worker 不是银弹，用之前确认这几项：
- 同源限制是否满足：Worker 脚本必须与主页面同协议、同域名、同端口；本地 file:// 打开会失败。
- DOM 依赖是否已剥离：Worker 中不能用 document、localStorage、alert，所有输入必须通过 postMessage 传入纯数据。
- 通信频率是否合理：避免高频小消息（如每毫秒发一次），应合并数据或使用 Transferable（如 ArrayBuffer）减少序列化开销。
- 是否及时终止：任务结束或页面卸载时调用 worker.terminate() 或在 Worker 内部 self.close()，防止后台线程长期空转耗资源。
