Web Worker 是消除主线程卡顿的唯一原生方案，需将超16ms的计算任务（如图像处理、大数据排序、加密等）移至独立线程，并用 Transferable Objects 实现零拷贝通信，同时做好错误兜底、复用池管理与超时控制。

要真正消除主线程的交互卡顿，关键不是“让计算快一点”，而是让计算彻底不碰主线程——Web Worker 是浏览器唯一能实现这点的原生机制。它不是优化技巧，而是架构级解耦：把纯计算逻辑剥离到独立线程，主线程只管 UI 渲染和用户响应。

哪些任务必须交给 Worker？

判断标准很简单：只要单次执行预期超过 16ms（即一帧时间），就该移出主线程。典型场景包括：

• 图像像素级处理（如 Canvas 滤镜、缩略图生成）
• 大数组排序/过滤（万行以上 CSV 或 JSON 解析）
• 加密解密、哈希计算（如 SHA-256、AES）
• 数学密集运算（矩阵乘法、素数筛、物理模拟）
• 二维码/条形码生成、PDF 文本提取等工具类逻辑

通信不能只靠 postMessage()，还要会“零拷贝”

频繁传大块数据反而更卡。结构化克隆会深拷贝整个对象，10MB 图像数据序列化可能耗时上百毫秒。正确做法是用 Transferable Objects：

• 主线程中拿到 ArrayBuffer 后，调用 postMessage({ buffer }, [buffer])，buffer 立即变 null
• Worker 内直接使用该 buffer，无拷贝开销
• 仅适用于 ArrayBuffer、MessagePort、ImageBitmap 等可转移类型
• 避免传普通对象嵌套过深，优先传 typed array 或 flat 数据结构

Worker 初始化和错误必须显式兜底

Worker 加载失败或内部报错，默认静默——UI 可能一直转圈，你却收不到任何提示：

• 主线程创建时检查 worker.onerror，捕获加载或初始化异常
• Worker 脚本顶部加 self.onerror = e => self.postMessage({ type: 'error', error: e.message })
• 路径必须同源，Vite/Webpack 项目需声明 { type: 'module' }，否则 import 会失败
• 禁止用 data: URL 或内联脚本创建，多数浏览器已禁用

别让 Worker 成为新瓶颈：合理复用与超时控制

每次 new Worker() 都有启动开销，高频小任务反复创建反而拖慢整体性能：

• 用 Worker Pool 管理固定数量实例（建议数量 ≤ navigator.hardwareConcurrency）
• 每个 Worker 复用处理多个请求，用 message type 区分任务类型
• 主线程发任务时带 timeout ID，Worker 超时未响应则主动终止并重试
• 长期空闲 Worker 可调用 worker.terminate() 释放资源