学js性能分析要建立“问题→现象→工具→证据→修复”闭环，先定位卡顿场景（点击延迟/滚动掉帧/输入卡顿），再按瓶颈类型选用performance面板、performanceobserver或内存采样等工具精准诊断，最后用缓存、节流、复用对象等手段修复并验证。
学 JS 运行时性能分析，不靠死记工具菜单，而要建立“问题→现象→工具→证据→修复”的闭环思维。重点不是会点几个按钮，而是看懂主线程在那一帧里到底被什么卡住了。
从真实卡顿场景倒推分析路径
别一上来就打开 Performance 面板录屏。先问自己三个问题：
- 用户在哪一刻觉得“卡”？是点击后延迟响应、滚动突然掉帧，还是输入框打字卡顿？
- 这个卡顿是否可复现？能否在 DevTools 中稳定触发（比如快速滚动列表、连续点击按钮）？
- 卡顿发生时，页面有没有做明显动作？比如加载数据、渲染新模块、执行日志打印、调用 getBoundingClientRect？
答案越具体，后续选工具就越准。例如“滚动中每滑一段就抖一下”，大概率指向样式计算或内存抖动；“点按钮后等了半秒才有反馈”，优先查 long task 和同步序列化。
按瓶颈类型匹配核心工具链
不同卡顿有不同指纹，工具不是通用的，要对症下药：
- 微观掉帧（10–50ms 级抖动）：用 Chrome Performance 面板 + “Screenshots”和“Web Vitals”开启录制，悬停 FPS 轨道看单帧内是否有黄色/红色长条，点开 Main 轨道按 Self Time 排序找叶子函数
- 看不见的瞬时卡顿（后台定时器、空闲时间被占）：写 PerformanceObserver 主动监听 longtask、layout-shift、paint，duration 设为 10ms 起报，捕获不可录制的扰动
- 滚动/悬停卡顿：重点筛 Performance 中的 Recalculate Style 和 Layout 事件，看 Details 面板里触发源是不是 offsetTop、getComputedStyle 这类强制同步布局属性
- 内存型卡顿（频繁 GC 导致帧不稳）：Performance 录制时勾选 Memory，看蓝色 V8.GC 竖条是否密集；再切 Memory 面板用 Allocation Sampling 找 map 回调、getBoundingClientRect 封装这类高频小对象创建点
用轻量手段快速验证与定位
不用每次启动大工具。日常排查可组合这些低成本方法：
- 用 console.time('label') 包住可疑逻辑，比如 console.time('render'); renderList(); console.timeEnd('render');——标签名区分大小写，避免循环内重复调用重置计时
- 怀疑 JSON.stringify 或 console.log 大对象？直接测：console.time('stringify-5k'); JSON.stringify(Array.from({length: 5000}, (_, i) => ({id:i}))); console.timeEnd('stringify-5k');
- 想确认某段代码是否真在主线程阻塞？加 performance.now() 前后打点，比 Date.now() 更精准，不受系统时钟跳变影响
- 高频事件回调（如 scroll/mousemove）里读写混杂？先手动节流到 16ms 一次，再对比 Performance 面板中 Recalculate Style 是否显著减少
把分析结果转化为可落地的修复
工具只告诉你“哪里慢”，修复要落在代码上：
- 发现 layout 强制同步？把 offsetHeight 缓存起来，或改用 getBoundingClientRect() 一次取全量
- 看到大量 Array / Object 分配？把 list.map(item => ({...item})) 改成复用结构体，或直接传 item，用点号访问字段
- long task 来自日志库自动格式化？开发环境关掉 prettyPrint，或用 structuredClone 前先 shallow copy 关键字段
- GC 密集区紧挨着某个 update 函数？检查它是否在循环中反复 new Date()、调用 getComputedStyle、或创建闭包
每次改完，回到 Performance 面板重录——看对应长条是否变短、变少、消失。能观察到变化，才算真正闭环。
