JavaScript卡顿主因是主线程过载、微任务爆炸、渲染被挤占和定时器失控；需通过Performance面板定位长任务，分片计算、Web Worker、读写分离、requestAnimationFrame及及时清理定时器来优化。
JavaScript 是单线程语言，靠事件循环（Event Loop）协调同步任务、异步回调与渲染，但一旦主线程被长时间阻塞，就会出现明显卡顿——这不是“卡死”，而是用户交互或动画掉帧、响应延迟的预警信号。
主线程过载：同步代码执行太久
比如遍历百万级数组、复杂正则匹配、未优化的 JSON.parse 大字符串，或递归过深，都会让调用栈持续占用主线程，导致宏任务队列无法及时轮转，UI 更新滞后。
- 用 Chrome DevTools 的 Performance 面板 录制操作，关注 Main 线程的长任务（Long Task，>50ms），标红即为卡顿风险点
- 将大计算拆成微任务分片（如用 queueMicrotask 或 Promise.resolve().then），让出控制权给渲染和事件处理
- 对纯计算密集型逻辑，优先考虑 Web Worker，彻底移出主线程
微任务爆炸：Promise 链无限嵌套或误用
每个微任务执行完会清空整个微任务队列，若在微任务中又不断创建新微任务（如错误的递归 Promise.then），会导致主线程无法进入下一轮宏任务，页面完全失去响应。
- 避免在 then/catch 回调中无条件触发新的 Promise，尤其注意节流/防抖逻辑中的微任务滥用
- 用 setTimeout(fn, 0) 替代部分非必须的微任务调度，主动让渡给宏任务队列，缓解饥饿
- 在开发阶段启用 Chrome 的 “Disable JavaScript microtask queue” 实验性调试选项（chrome://flags），辅助定位问题
渲染被挤占：高频同步 DOM 操作 + 强制同步布局
频繁读写 DOM（如循环中反复访问 offsetHeight、getBoundingClientRect）会触发浏览器强制同步回流（reflow），而回流是昂贵且阻塞的，叠加大量样式计算，极易造成帧率骤降。
立即学习“Java免费学习笔记（深入）”；
- 批量读取布局信息（如先收集所有 offsetTop，再统一读），遵循 读-改-写 分离原则
- 用 requestAnimationFrame 调度视觉更新，在下一帧开始前完成 DOM 修改，与浏览器刷新节奏对齐
- 对动态列表等场景，启用 CSS contain: layout paint 或虚拟滚动，减少实际渲染节点数
定时器失控：setInterval/setTimeout 嵌套过深或未清理
未清除的定时器可能在页面隐藏后继续执行，积累微任务或触发不必要的重绘；更隐蔽的是，短间隔（如 1ms）定时器在主线程繁忙时会“积压”，恢复后集中爆发，形成瞬时负载高峰。
- 始终用 clearInterval / clearTimeout 配合组件卸载或状态变更清理定时器
- 避免使用 0ms 定时器 模拟轮询，改用 requestIdleCallback（如有兼容性要求可降级为 setTimeout）处理低优先级后台任务
- 对动画类逻辑，优先使用 requestAnimationFrame 而非 setInterval，它天然受帧率限制且自动暂停于页面不可见时
卡顿不是玄学，是主线程时间分配失衡的明确反馈。关注长任务、微任务节奏、布局触发时机和定时器生命周期，就能把 Event Loop 从“黑盒”变成可观察、可干预的运行节拍器。
