卡顿本质是主线程被占满，需用Chrome DevTools Performance面板定位长任务（＞50ms红色块）、微任务风暴、DOM读写混搭、定时器泄漏及事件监听器积压等问题。
卡顿本质是主线程被占满，导致用户操作、动画、渲染来不及响应。关键不是“哪里慢”，而是“谁在霸占主线程”。分析要直奔源头，用工具定位具体函数和执行模式。
看长任务：Performance 面板抓“红色块”
打开 Chrome DevTools → Performance 面板 → 勾选 “Screenshots” 和 “JS Profile” → 录制一次卡顿操作（比如滚动或点击）→ 停止后看火焰图：
- 主线程（Main）里出现持续超过 50ms 的红色长条，就是典型长任务，点开能直接看到是哪个函数在跑
- 重点关注 for 循环遍历大数据、JSON.parse 大字符串、正则 test/replace 耗时、递归没出口 这类同步密集型代码
- 如果长任务集中在某个第三方库方法里，说明它没做分片或异步处理，需封装或替换
查微任务风暴：别让 Promise 链把自己绕死
页面完全冻结、控制台无报错但交互全失，大概率是微任务失控：
- 在 Performance 面板中筛选 “Microtask queue”，若它持续高负载、几乎不中断，就是微任务没完没了
- 典型写法：
Promise.resolve().then(() => { /* 又调用一次 resolve */ })或queueMicrotask里递归调用自己 - 临时验证：在 chrome://flags 开启 “Disable JavaScript microtask queue”，如果卡顿消失，基本锁定问题
盯 DOM 操作：读写混搭触发强制回流
滚动、拖拽、列表更新卡顿，常因 DOM 读写耦合太紧：
立即学习“Java免费学习笔记（深入）”；
- 在循环里反复读
offsetHeight、getBoundingClientRect()，再立刻改style.left，每次读都会强制同步计算布局 - 用 Performance 面板的 “Layout” 分类查看是否频繁出现 Layout / Update Layer 标签
- 优化方向：批量读取所有需要的尺寸 → 批量修改样式 → 用
requestAnimationFrame包裹视觉更新
验定时器与监听器：积压、泄漏、高频轰炸
页面切到后台又切回来突然卡一下，或滚动越久越慢，往往跟定时器或事件监听有关：
- 检查
setInterval(fn, 1)或setTimeout(fn, 0)是否没清理，尤其在组件卸载时漏掉clearInterval - 滚动/缩放等高频事件是否没节流，导致每帧都往队列塞一堆回调
- 用 Memory 面板拍两次堆快照，对比 “Detached HTML Elements” 是否持续增长，说明 DOM 节点没释放，间接拖慢事件循环
不复杂但容易忽略：卡顿不是玄学，是主线程资源被谁抢了、怎么抢的、抢了多久。从 Performance 面板起步，盯着 Main 线程和 Microtask queue，再结合代码逻辑反推，就能快速定位真正瓶颈。
