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' 才危险。只要读写交替，浏览器就可能被迫同步计算样式和布局。
常见陷阱包括：
立即学习“Java免费学习笔记（深入）”；
- 在一个循环里反复读取
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）避免拷贝开销。
