17370845950

Chrome DevTools Performance面板抓问题需录制3–5秒复现卡顿的操作，重点关注红色长条（JS执行过久）、频繁紫/绿色块（强制同步布局）、大量灰色Script Evaluation（未节流回调）；内存泄漏用Heap snapshot对比Detached DOM树增长；requestIdleCallback适用于可中断低优先级任务，Web Worker用于CPU密集型纯计算。

Chrome DevTools 的 Performance 面板怎么抓准问题？

直接录一段用户操作（比如点击按钮后页面卡顿），而不是随便点几下就停止录制。关键是要复现「慢」的场景，且录制时间控制在 3–5 秒内——太长会淹没关键帧，太短可能漏掉 setTimeout 或 requestIdleCallback 触发的延迟任务。

重点关注以下三类高亮区域：

• 红色长条：主线程长时间阻塞，大概率是 JS 执行过久，点开看 Bottom-Up 标签页，找 Self Time 最高的函数
• 频繁的紫色 Layout / 绿色 Paint：说明触发了过多强制同步布局（offsetTop、getComputedStyle 等读取布局 API 被反复调用）
• 大量灰色 Script Evaluation：可能是事件监听器没节流，或 resize/scroll 回调里做了重计算

哪些 JS 操作会意外触发重排重绘？

不是只有 style.width = '200px' 才危险。只要读写交替，浏览器就可能被迫同步计算样式和布局。

常见陷阱包括：

• 在一个循环里反复读取 element.offsetHeight，再修改 element.style.left
• 使用 getBoundingClientRect() 后立刻修改 class，又马上读 clientWidth
• for...of 遍历 NodeList 时，在每次迭代中都调用 el.offsetTop

正确做法是：把所有读操作集中到前面，所有写操作集中到后面；或者用 document.createDocumentFragment() 批量更新 DOM。

如何快速定位内存泄漏？

打开 Chrome DevTools 的 Memory 面板，选中 Heap snapshot，做三次操作：拍快照 → 执行疑似泄漏的操作（如打开关闭弹窗 5 次）→ 再拍快照 → 重复一次。对比第三次快照中 Detached DOM tree 的数量是否持续增长。

重点检查：

• 全局变量意外持有 DOM 引用，比如 window.cacheEl = document.getElementById('modal')
• 事件监听器没用 removeEventListener 清理，尤其用 addEventListener 传了匿名函数
• 闭包中引用了大对象（如整个 response.data），但只用其中几个字段

示例：下面这段代码会让 data 无法被回收

function loadData() {
  const response = await fetch('/api');
  const data = await response.json();
  return function() {
    console.log(data); // 闭包捕获了整个 data 对象
  };
}

requestIdleCallback 和 Web Worker 什么时候该用？

requestIdleCallback 适合处理低优先级、可中断的任务，比如日志上报、非关键 UI 更新。但它不保证执行（空闲时间不足时会被跳过），也不能用于必须完成的逻辑。

Web Worker 是唯一能真正把 CPU 密集型任务移出主线程的方式，比如解析大 JSON、图像处理、复杂计算。注意它不能访问 DOM，通信靠 postMessage。

选择依据：

• 耗时 setTimeout 或 requestIdleCallback
• 耗时 > 50ms 且需 DOM 操作 → 拆成小块 + setTimeout 分帧
• 耗时 > 50ms 且纯计算 → 必须用 Web Worker

别在 Worker 里传大对象，用 transferable（如 ArrayBuffer）避免拷贝开销。

实际优化中最容易被忽略的是：**重排重绘的触发成本远高于 JS 执行本身，而开发者往往只盯着 CPU 时间线看函数耗时**。