JS性能分析速查手册：1. Performance面板三步定位卡顿——录制定位长任务与强制同步布局；2. Memory面板双快照比对查内存泄漏；3. 高频低效操作清单直指scroll/input中未节流、DOM频繁读写、for...in遍历等典型问题。
编写一份实用的 JS 运行时性能分析速查手册，核心是聚焦高频场景、关键指标和可立即执行的操作，避免理论堆砌。它不是完整指南，而是开发者打开 DevTools 后能 30 秒内定位瓶颈的“操作地图”。
一、快速定位卡顿源头：Performance 面板三步法
打开 Chrome DevTools → Performance 标签 → 点击录制（●）→ 操作页面 → 停止录制。
- 先看火焰图顶部的主线程高度：持续高耸（尤其 >50ms 的长条）说明 JS 执行过久，重点看“Main”轨道下的函数调用栈
- 关注红色警告图标：点击它会直接跳转到对应帧，显示“Long Task”或“Forced Synchronous Layout”，这是最常被忽略的首因
- 按“Ctrl+F”搜关键词：如 "render"、"update"、"compute" 或你项目中常见的模块名，快速过滤无关调用
二、内存泄漏自查：Memory 面板两个快照比对
适合怀疑组件卸载后对象未释放（如事件监听器、定时器、闭包引用）。
- 在疑似泄漏前，点 “Take heap snapshot”（记为 Snapshot 1）
- 触发操作（如打开/关闭弹窗、切换路由），再点一次（Snapshot 2）
- 切换到 “Comparison” 视图，筛选 “Constructor” 列中 Delta > 0 且 #Delta 显著上升的类型（如 Closure、EventTarget、自定义类名）
- 双击该行 → 右侧看 retaining path：从 GC root 到该对象的引用链，找到谁“拽着它不放”
三、高频低效操作速查清单（直接对标代码）
以下模式一旦出现，几乎必然拖慢运行时，建议在 Code Review 或 PR 中主动扫描：
- 在 scroll / resize / input 事件中直接调用 heavy 函数 → 改用 throttle（防抖）或 debounce（节流），或移交 requestIdleCallback
- 循环中频繁读写 DOM 属性（如 offsetTop、getBoundingClientRect()）→ 提前缓存，或用 document.querySelector + getComputedStyle 批量读取
- 使用 for...in 遍历数组 → 改用 for (let i = 0; i 或 arr.forEach（V8 对后者有优化）
- 大数组 map/filter 后立刻展开（...arr.map(...)） → 考虑用 for 循环 + 条件 push，避免中间数组创建
四、轻量级线上监控：用 performance.now() + 自定义指标
不依赖工具，也能捕获真实用户卡顿：
- 在关键路径开头记时间：const start = performance.now()
- 在结束处计算并上报：if (performance.now() - start > 100) reportSlowTask('list_render')
- 结合 window.addEventListener('beforeunload', ...) 上报未完成的长任务（如异步加载未结束就跳转）
- 用 performance.getEntriesByType('navigation') 检查 domComplete 和 loadEventEnd 差值，判断 JS 执行是否阻塞了交互就绪
