掌握JS性能分析需建立“问题→指标→证据→干预”闭环：识别强制同步布局、高频长任务、内存渐进泄漏等真实瓶颈，结合火焰图、longtask、Memory面板及performance API精准定位并优化。
掌握 JS 运行时性能分析，关键不是堆工具，而是建立“问题→指标→证据→干预”的闭环思维。很多开发者卡在“看到火焰图但看不懂哪一行该优化”，根源在于没对齐真实瓶颈和测量方式。
别被“高 CPU 占用”带偏方向
Chrome DevTools 的 Performance 面板里，主线程红色长条常被当成“CPU 过载”，但实际可能只是强制同步布局（forced synchronous layout）——比如在循环中反复读取 offsetHeight 或 getBoundingClientRect()。浏览器不得不暂停 JS 执行、立即回流、再继续，造成时间堆积。
- 检查火焰图中是否密集出现
Layout或Recalculate Style，而非Script Evaluation - 把多次 DOM 查询合并：缓存一次结果复用，或改用
ResizeObserver/IntersectionObserver替代轮询 - 避免在
for循环里写el.style.left = i + 'px'; console.log(el.offsetHeight);这类组合
长任务不等于“函数太慢”，而常是“不该在主线程干的事”
一个 80ms 的函数，如果只调用一次，影响有限；但如果它在滚动、输入、动画帧中高频触发（如 input 事件未防抖），就会持续挤压渲染时间，导致掉帧。
- 用
performance.getEntriesByType('longtask')精确捕获哪些任务超 50ms，注意看name字段——是你的函数名？还是setTimeout回调？或是第三方 SDK 的初始化？ - 高频事件处理必须加节流：
debounce适合表单校验，throttle更适合滚动监听 - 真正耗时的计算（如解析大 JSON、图像处理）应移入
Web Worker，主线程只负责通信与 UI 更新
内存泄漏的信号往往藏在“稳定增长”里
不是内存爆满才叫泄漏，而是页面交互后内存未回落，且每次操作都比上次多出固定增量。常见于事件监听器未清理、闭包意外持有 DOM 引用、定时器未清除。
- 在 Memory 面板中录制“打开组件 → 操作 → 关闭组件 → 等待 5 秒 → 垃圾回收（GC）”流程，对比前后内存占用
- 重点检查
addEventListener是否配对了removeEventListener；若只需执行一次，直接加{ once: true } - 避免在回调中引用外部大对象（如整个
state或ref.current），可只传必要字段
调试技巧要嵌入开发节奏，而非等出问题才启动
性能问题很难“复现”，但可以“预防”。把轻量监控变成日常习惯：
- 在关键函数开头加
performance.mark('fn-start')，结尾加performance.mark('fn-end')和performance.measure，用performance.getEntriesByName收集数据 - 开发环境启用
window.DEBUG_PERF = true，配合条件日志输出耗时，上线前统一关闭 - 对第三方脚本（尤其是埋点、广告 SDK）单独测加载和运行开销，用
PerformanceObserver监听resource和script类型条目
