HTML不是多线程语言，卡顿源于JavaScript主线程阻塞；Web Workers可独立线程执行计算任务，但无法操作DOM；setTimeout和requestIdleCallback通过让出主线程控制权防卡顿，后者更精准但兼容性较差。
HTML 本身没有多线程
直接说结论：HTML 是标记语言，不执行逻辑，谈不上“多线程”。你遇到的卡顿，根源在 JavaScript 主线程阻塞，而浏览器对 JS 的执行是单线程的（主线程负责渲染、事件、脚本执行）。所谓“HTML 多线程”其实是误传，真正能缓解卡顿的是 Web Workers、requestIdleCallback 或拆分耗时任务到微任务/宏任务队列。
为什么用 Web Workers 能缓解卡顿
主线程一忙，页面就冻结：滚动、点击、动画全卡住。而 Web Workers 在独立线程运行 JS，不占用主线程，适合做计算密集型工作（如解析大 JSON、加密、图像处理）。
实操注意点：
-
Worker无法访问window、document、DOM，所有数据靠postMessage传递，且只能传可序列化的值（不能传函数、Element、Promise等） - 频繁通信有开销，别用它传几 MB 的数组来回拷贝；大数据建议用
Transferable（如ArrayBuffer）避免复制 - 创建 Worker 需要同源脚本路径，
new Worker('./calc.js')中的路径必须是网络可访问的 URL，不能是内联字符串或 blob URL（除非显式构造Blob+URL.createObjectURL）
setTimeout 和 requestIdleCallback 不是多线程，但能防卡顿
它们不创建新线程，而是把任务“让出”主线程控制权，等浏览器空闲时再执行，避免长任务阻塞渲染帧。
立即学习“前端免费学习笔记（深入）”；
适用场景和差异：
-
setTimeout(fn, 0)把任务推到下一个宏任务队列，至少等待一次事件循环，但无法保证时机，可能被其他高优先级任务（如用户输入）挤压 -
requestIdleCallback更精准：只在浏览器空闲时段（如帧末尾）执行，且能拿到剩余空闲时间（deadline.timeRemaining()），适合渐进式处理大列表、懒解析等 - 注意：
requestIdleCallback不是所有环境都支持（如 Safari 曾长期不支持），需降级到setTimeout或requestAnimationFrame
哪些“伪多线程”操作反而加重卡顿
开发者有时误以为“拆成多个 setTimeout”或“用 async/await 包一层”就算解耦，其实没释放主线程压力。
典型踩坑点：
- 在
for循环里连续调用setTimeout（如每轮 0ms），大量定时器注册会撑爆任务队列，触发 V8 的 GC 压力，反而更卡 - 用
async函数包装同步大循环（如for (let i = 0; i ），只是加了 Promise 封装，循环体仍在主线程跑满 16ms+，照样掉帧 - 滥用
innerHTML批量插入千条 DOM 节点——即使分多次，每次仍触发重排重绘；应改用DocumentFragment或createDocumentFragment缓存后一次性挂载
真正的瓶颈往往不在“有没有线程”，而在“是否把不该放主线程的事硬塞进去了”。比如前端做 ZIP 解压、PDF 渲染、实时音视频编解码——这些必须移出主线程，否则再怎么切片也救不回来。
