掉帧本质是主线程单帧执行超16.6ms致渲染延迟；用performance面板flamechart定位，关注frames轨道中宽度＞25ms的异常帧及对应main轨道耗时任务。
页面掉帧（Jank）本质是主线程在某一帧内执行时间超过 16.6ms（60fps），导致浏览器无法按时完成渲染，从而出现卡顿。Performance 面板的 Flamechart 是最直接的可视化工具，能精准定位耗时长的任务来源。
看 Flamechart 的关键区域：主线程（Main）与帧标记（Frames）
打开 Chrome DevTools → Performance → 点击录制（●）→ 操作页面 → 停止录制。重点观察顶部的 Frames 轨道（绿色小方块）和下方的 Main 轨道（火焰图主体）：
- Frames 轨道中，宽度正常应为 ~16.6ms；若某帧明显变宽（比如 >25ms），就是掉帧帧，记下其时间戳
- Recalculate Style、Layout、Paint、Composite Layers 的条目，它们属于渲染流水线关键阶段，频繁或耗时过长极易引发 Jank
识别典型掉帧诱因：强制同步布局（Forced Layout）与重绘风暴
Flamechart 中若出现大量连续的 Layout 条目（尤其夹在 JS 执行中间），大概率是强制同步布局：
- el.offsetLeft、
el.getBoundingClientRect()、getComputedStyle(el).height等读取布局信息后，紧接着修改样式（如el.style.width = '100px'） - Update Layer Tree 或 Paint（尤其大范围
opacity、transform缺少 will-change / contain 优化），也会在 Flamechart 中堆叠出密集的绘制条目
快速定位问题 JS 函数：从长任务入口逐层下钻
Flamechart 中一个宽 >16ms 的 JS 任务（蓝色/黄色矩形）就是首要嫌疑对象：
- Self Time（自身耗时）和 Total Time（含子调用总耗时）
- setTimeout 或
requestIdleCallback回调若执行过久，也会出现在 Main 轨道中对应时间点，需结合时间轴定位 - Garbage Collection（GC）事件紧邻长任务，说明内存压力大，可能触发频繁回收，间接加剧掉帧
验证修复效果：对比录制 + 关注 FPS 曲线
修改代码后，务必重新录制并比对：
- FPS Meter（右键 Frames 轨道 → “Show FPS meter”），直观观察帧率是否稳定在 60
- requestIdleCallback / Web Worker？Layout/Paint 是否显著减少？
- Bottom-Up 标签页，按 Self Time 排序，确认高耗时函数是否已优化或降权
