JavaScript性能优化关键在规避DOM重排/重绘、主线程长任务阻塞、内存持续增长；高效DOM操作用DocumentFragment批量挂载，闭包慎捕大对象，requestIdleCallback需防超时与兼容性问题。
JavaScript 性能优化不是靠堆技巧，而是盯住三个真实瓶颈：DOM 重排/重绘、主线程被长任务阻塞、内存持续增长却无法回收。多数卡顿和内存泄漏，80% 出在写法细节里，而不是引擎不够快。
怎么批量操作 DOM 才不触发上百次重排？
每次 el.appendChild() 或改 innerHTML 都可能强制浏览器同步计算布局——连续 100 次，就是 100 次重排。
真正高效的写法是把所有节点先“攒”在内存里，最后一次性挂载：
const fragment = document.createDocumentFragment();
for (let i = 0; i < 1000; i++) {
const div = document.createElement('div');
div.textContent = `Item ${i}`;
fragment.appendChild(div);
}
document.body.appendChild(fragment); // ✅ 只触发 1 次重排⚠️ 容易踩的坑：
• 不要用 innerHTML += 循环拼接（每次赋值都清空再重建）
• 不要缓存 document.body 后反复调用 appendChild()（仍会逐次重排）
• DocumentFragment 是隐形容器，插入时只挂载子节点，不把自己挂进 DOM 树
节流（throttle）和防抖（debounce）到底该用哪个？
滚动、鼠标移动这类**持续高频触发**的事件，必须用 throttle；而输入框搜索、窗口缩放这种**停顿后才需响应**的，才用 debounce。
立即学习“Java免费学习笔记（深入）”；
常见错误：
• 把 resize 直接套 debounce（合理），但把 scroll 也套 debounce（会导致滚动中完全没响应）
• 用 Lodash 的 _.throttle 却没传 { leading: true, trailing: true }（首尾调用会被丢掉）
一个轻量可靠的 throttle 实现：
function throttle(fn, delay) {
let last = 0;
return function(...args) {
const now = Date.now();
if (now - last >= delay) {
fn.apply(this, args);
last = now;
}
};
}闭包真的慢吗？什么情况下它会悄悄吃掉内存？
闭包本身不拖慢执行，但若它捕获了本不该长期持有的大对象（比如整个 dataList 数组或某个 DOM 节点），又绑定在全局事件上（如 window.addEventListener('scroll', handler)），那这个闭包就一直活在内存里，垃圾回收器无法释放它。
排查方法：
• 打开 Chrome DevTools → Memory 面板 → “Heap Snapshot” 对比前后差异
• 在事件监听器里避免写 el.addEventListener('click', () => doSomething(largeData))
• 改用预绑定或外部函数：const handler = createHandler(largeData); el.addEventListener('click', handler)
• 存私有数据优先用 WeakMap（键对象被回收时，对应值自动消失）
requestIdleCallback 是不是万能的“后台任务”开关？
它确实能把非关键逻辑（如日志上报、低优状态更新）塞进浏览器空闲时段，且可被中断，不抢主线程——但它有硬限制：
• 最多执行 50ms，超时自动暂停
• IE 完全不支持，必须降级为 setTimeout(fn, 0) 或引入 polyfill
• 不适合需要精确时机的任务（比如动画帧同步），这种场景该用 requestAnimationFrame
典型误用：
• 把一个需 200ms 的数据处理直接丢给 requestIdleCallback（它会分多次执行，中间可能被中断）
• 在页面刚加载时密集调用它（此时浏览器并不“空闲”，可能根本不执行）
真正卡顿的代码，往往没有报错，也不抛异常，只是让 Performance 面板里 Layout 和 Scripting 时间栏悄悄变红。优化的关键，是养成「改一行代码前，先看它对重排、主线程、内存三者的影响」的习惯。
