Web Workers能解决主线程卡顿，关键在于将耗时≥50ms且不依赖DOM的纯CPU计算任务（如大数据排序、图像处理、加密解密、AI推理）剥离至独立线程执行，通过消息传递与transferable优化通信，避免主线程阻塞。
能解决，但关键不在“开了几个线程”，而在于把真正耗CPU的计算任务从主线程剥离出去。Web Workers不是万能加速器，它只对纯计算型长任务有效——比如大数组处理、图像像素运算、加密解密，而不是让DOM操作变快或让网络请求提速。
哪些计算值得放进Worker
判断标准很实在：单次执行耗时 ≥ 50ms，且不依赖页面元素。
- 处理上万条数据的排序、聚合、路径规划
- Canvas图像滤镜（灰度、卷积、缩放）或视频帧分析
- 解析几MB的JSON/CSV、文本分词、正则批量匹配
- 前端加密（AES、RSA）、哈希计算、压缩解压
- 离线AI推理（如TinyML模型前向计算）
怎么写才不白忙活
光建个Worker文件还不够，通信和内存管理出错反而更卡。
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 用 transferable 传大数据：比如
worker.postMessage(buffer, [buffer])，避免ArrayBuffer被拷贝两份，尤其在低端安卓机上容易爆内存 - 别在Worker里调
console.log，尤其循环中——它会同步回传主线程，变成隐式瓶颈 - Worker脚本路径要绝对可靠：SPA项目里
new Worker('./worker.js')很可能404，建议用new URL('./worker.js', import.meta.url)（ESM环境）或配好public静态路径 - 高频触发场景（如拖拽、滚动）别每帧发消息，改用节流 + 批量打包数据再传
主线程该做什么，不该做什么
Worker再强，也救不了主线程自己作出来的卡顿。
立即学习“前端免费学习笔记（深入）”；
- ✅ 应该做：接收Worker结果、更新UI状态、调度动画帧（
requestAnimationFrame）、响应用户点击 - ❌ 绝对不做：在Worker返回前还反复操作DOM（比如边算边改class）、监听大量
resize/scroll并直接跑逻辑、用setTimeout模拟长任务却不分片 - ⚠️ 注意：localStorage读写、简单JSON.parse(
要不要开多个Worker
不是越多越好，Chrome默认限制每个页面最多约20个Worker，且真实并发受渲染进程调度约束。
- 优先复用已有Worker实例，避免频繁
new Worker()和terminate() - 想压满多核？别硬凑数量，可用
navigator.hardwareConcurrency参考，但上限建议设为Math.min(4, navigator.hardwareConcurrency) - 跨标签页共享状态？用 SharedWorker，但需同源且注意生命周期管理
- 真需要零拷贝共享内存？考虑
SharedArrayBuffer + Atomics，但必须服务端配COOP/COEP头，移动端支持仍有限
