html本身无多线程，javascript主线程卡顿导致页面冻结；web worker提供真正多线程，但无法操作dom，仅适用于cpu密集型任务如大json解析、图像处理等。
HTML 本身没有多线程，但 JavaScript 有 Web Worker
很多人搜“HTML 多线程”，其实想问的是“能不能让 HTML 页面不卡”——但 HTML 是标记语言，不执行逻辑，真正卡顿的源头是 JavaScript 主线程。浏览器只给每个页面分配一个 JS 主线程（渲染 + 事件 + 脚本），所有 document 操作、setTimeout、fetch 回调、addEventListener 都挤在这条线上。一旦某段 JS 跑太久（比如循环 10 万次、解析大 JSON、复杂计算），页面就冻结：按钮点不动、滚动卡住、动画掉帧。
真正的“多线程”能力来自 Web Worker，它在独立线程运行 JS，**完全不接触 DOM**，只能靠 postMessage 和主线程通信。所以别指望用 Worker 直接操作 document.getElementById——那会报错：DOMException: Failed to execute 'postMessage' on 'DedicatedWorkerGlobalScope'（实际错误更可能是 ReferenceError: document is not defined）。
什么时候该用 Web Worker？看 CPU 密集型任务
不是所有异步都该塞进 Worker。HTTP 请求、定时器、动画帧（requestAnimationFrame）本来就不阻塞主线程，强行丢进 Worker 反而增加序列化开销和通信延迟。
- 适合 Worker 的场景：
JSON.parse超大字符串、加密解密（如SubtleCrypto）、图像像素处理（ImageData计算）、离线数据聚合、大型数组排序/过滤 - 不适合的场景：
fetch请求本身（它已是异步非阻塞）、localStorage读写（IO 快，但 Worker 里根本不能用）、任何涉及document、window、console（Worker 里只有self、postMessage、importScripts） - 注意参数传递：传对象会触发结构化克隆（深拷贝），大数据量（如百 MB ArrayBuffer）建议用
transferable（如postMessage(data, [data.buffer])）避免拷贝
Worker 用错反而更卡：常见坑点
Worker 不是银弹，用不好会放大卡顿。
- 频繁通信：每 16ms（一帧）发一次
postMessage，主线程忙于解析消息，比直接计算还慢；应批量聚合结果再上报 - Worker 启动开销：创建
new Worker('path.js')需加载脚本、初始化上下文，短任务（ - 内存泄漏：Worker 实例未调用
worker.terminate()，或主线程监听了worker.onmessage却没清理，长期驻留吃内存 - 调试困难：Chrome DevTools 的 Sources 面板默认不显示 Worker 脚本，需手动打开
Settings → Preferences → Advanced → Enable worker debugging
比 Worker 更轻量的防卡方案
多数卡顿不需要上 Worker，先试试这些低成本手段：
- 把长任务拆成微任务：用
queueMicrotask或Promise.resolve().then()让出主线程，保证 UI 可响应（适合分片处理数组） - 用
requestIdleCallback在浏览器空闲时执行低优先级任务（如日志上报、预加载），但注意兼容性（IE 不支持，Safari 旧版有 bug） - 用
IntersectionObserver替代滚动监听：避免scroll事件高频触发导致重排重绘 - CSS 动画交给
transform和opacity：它们走合成线程（Compositor Thread），不经过 JS 主线程
真正需要 Worker 的，往往是用户明确感知到“点了按钮等 3 秒才出结果”的场景。这时候得测真实耗时——用 performance.now() 包裹关键段，确认是不是 CPU 瓶颈，而不是网络或渲染拖慢。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
