直接打开Performance面板录制操作，火焰图中宽而高的黄色块即为拖慢页面的JS代码；需通过Bottom-Up视图按总耗时排序定位瓶颈函数，结合Call Stack追溯调用路径，并用Screenshots、CPU节流与Disable cache辅助精准分析。
直接打开 Performance 面板录制操作，看火焰图里宽而高的黄色块——那就是拖慢页面的 JS 代码。关键不是“找慢”，而是定位到具体函数、调用路径和触发时机。
录一段真实操作，别只看空转
在 Performance 面板点红色录制按钮（●），然后做你要分析的动作：比如点击按钮、滚动列表、切换 Tab。不要等页面空闲再停，要覆盖完整交互周期。结束后火焰图会自动展开，时间轴上标出 FPS、内存、主线程活动等轨道。
- 确保勾选 “Screenshots” —— 可以对照画面卡顿帧，精准对齐 JS 执行时刻
- 禁用缓存（Network → Disable cache）+ 开启 CPU 节流（如 4x slowdown）—— 模拟中低端设备，让慢代码更明显
- 若分析滚动卡顿，用鼠标滚轮或触摸板连续滚动 2–3 秒，避免单次微动干扰判断
盯紧火焰图里的三类异常信号
火焰图横轴是时间，纵轴是调用栈。JS 执行显示为黄色块，越宽越耗时，越深越嵌套多。重点抓：
- 单帧内 >16ms 的黄色长条：说明这一帧 JS 占用超预算，直接导致掉帧。点开它，看底部函数名和 Self Time
- 高频重复出现的小黄块：比如每 16ms 就来一次，大概率是 scroll/mousemove 事件里没节流的逻辑
- 黄色块下方紧挨着紫色（Recalculate Style）或绿色（Paint）块：说明 JS 不仅慢，还顺带强制布局或重绘，双重开销
用 Bottom-Up 视图揪出真正耗时的函数
录制完成后，切换到 Summary 下方的 Bottom-Up 标签。这里按“总耗时（Total Time）”倒序排列所有函数，顶部就是最大瓶颈。
立即学习“Java免费学习笔记（深入）”；
- 关注 “Self Time” 高但 “Total Time” 更高的函数——它本身不慢，但被反复调用，或调用了大量子函数
- 点开可疑函数，右侧 Call Stack 会显示谁调用了它。如果来自 addEventListener 或 requestAnimationFrame 回调，基本可确认是事件响应逻辑问题
- 若函数名含 node_modules 或 vendor.js，说明慢点在第三方库里，先查文档看是否有配置项可关闭/延迟加载
验证与复现：Console + 断点交叉确认
光看火焰图还不够，得动手验证。回到 Sources 面板，找到 Bottom-Up 里定位到的函数，在关键行打上断点；或者直接在 Console 输入：
-
console.time('test'); yourSuspectFunction(); console.timeEnd('test');—— 实测单次执行耗时 -
performance.mark('start'); /* 触发逻辑 */; performance.measure('delta', 'start');—— 获取高精度毫秒级数据 - 在 Elements 面板右键目标元素 → “Break on” → “attribute modifications” —— 若 JS 在疯狂改 class/style，这里能立刻中断并跳转到修改源头
