Web Worker能缓解卡顿，但仅对纯计算任务有效；用错会加重卡顿，因其不解决DOM或IO阻塞，且高频postMessage、不当通信或低端设备多实例反而引发新卡顿。
HTML 本身没有多线程，所谓“HTML 多线程”实际是误称；真正影响卡顿的，是 Web Worker 的使用方式是否合理——用对了能解卡顿，用错了反而加重卡顿。
Web Worker 为什么能缓解主线程卡顿
浏览器中 JS 主线程负责渲染、事件响应和脚本执行，三者挤在一条线上。一旦某段计算耗时超过 ~16ms（即一帧），动画掉帧、按钮点击无反馈、滚动卡住就全来了。Web Worker 在独立线程运行，不共享内存、不访问 document、不触发重排重绘，因此能把纯 CPU 密集型任务（如图像滤镜、加密、大数组排序）彻底移出主线程。
关键点在于：它只解决「计算阻塞」，不解决「DOM 阻塞」或「IO 阻塞」。
- 适合抽离的任务：斐波那契递归、
tfjs模型推理、CSV 解析、RSA 加密 - 不适合抽离的任务：
document.querySelector、element.style.width = '100px'、频繁fetch请求发起（网络本身异步，但回调仍回主线程） - 性能拐点建议：单次计算 ≥ 50ms 才值得开 Worker；小于这个量级，用
queueMicrotask或setTimeout(..., 0)分片更轻量
高频 postMessage 是卡顿新源头
Worker 和主线程通信靠 postMessage，看似无害，但高频调用（比如 mousemove 中每帧发一次）会迅速拖垮主线程消息队列，引发隐性卡顿。错误示例：worker.postMessage({x: e.clientX, y: e.clientY}) 在 60fps 下每秒发 60 次。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
立即学习“前端免费学习笔记（深入）”；
- 必须节流：用
requestAnimationFrame批量采集坐标，再一次性发给 Worker - 避免 JSON 序列化开销：传
ArrayBuffer、TypedArray等Transferable对象，否则内存翻倍 + GC 压力增大 - 不要在 Worker 里轮询等待结果：主线程别写
while (!done) {}，改用onmessage回调处理
Worker 脚本路径 404 是常见部署陷阱
new Worker('./utils/worker.js') 在 SPA 路由下极易 404，因为 Worker 请求路径基于当前 URL，不是项目根目录。比如页面地址是 https://site.com/dashboard/edit，浏览器实际请求的是 https://site.com/dashboard/edit/utils/worker.js，而非你预期的 /utils/worker.js。
- 推荐写法：
new Worker(new URL('./utils/worker.js', import.meta.url))（ESM 环境） - 兼容旧版：用绝对路径
new Worker('/static/worker.js')，并确保该路径被静态服务正确映射 - 注意：
importScripts在 Worker 内部不走模块解析，CDN 引入如importScripts('https://cdn.jsdelivr.net/npm/@tensorflow/tfjs@3.18.0/dist/tf.min.js')可用，但无法用import
移动端和低端设备上 Worker 可能反向加剧卡顿
Android 中低端机内存紧张，开多个 Worker 实例容易触发系统级内存回收，导致主线程被暂停（表现为页面突然黑屏 200–500ms）。同时，Worker 启动本身有 ~10–30ms 开销，小任务得不偿失。
- 必须限制 Worker 实例数：全局复用单个 Worker，用
message类型区分任务（如{type: 'blur', data: imgData}） - 主动降级策略：检测
navigator.hardwareConcurrency 或内存不足时，直接退回到主线程分片处理 - 记得
worker.terminate()：长期驻留的 Worker 会持续占用内存，尤其在单页应用路由切换后容易泄漏
真正难的不是“能不能用 Worker”，而是判断“该不该用”以及“怎么切分任务边界”。很多开发者一上来就套 Worker，结果发现卡顿没改善，是因为把 DOM 更新逻辑也塞进去了——而那部分根本跑不起来，还平白增加了通信成本。
