JavaScript性能优化关键是识别并解决主线程卡顿、内存泄漏和页面掉帧问题，包括批量DOM操作、合理使用节流防抖、避免闭包内存泄漏，以及用requestIdleCallback让出主线程。

JavaScript性能优化不是堆砌技巧，而是识别并切断那些让主线程卡住、内存涨不下去、页面掉帧的“真凶”。真正有效的优化，往往藏在你每天写的几行代码里——比如一次 DOM 查询、一个没清理的定时器、或者滚动事件里直接跑了个排序。

怎么批量操作DOM才不触发100次重排？

浏览器每修改一次元素几何属性（width、top、offsetHeight），就可能强制同步计算整个布局（Reflow），这是最贵的操作之一。连续改100次 el.style.left，等于让浏览器算100遍布局。

• ✅ 用 DocumentFragment：先把节点建在内存里，最后一次性挂载
• ✅ 用 innerHTML 或 cssText 批量写入样式，别逐个设 style.color、style.fontSize
• ✅ 读写分离：先集中读完所有 get

  

  BoundingClientRect()、offsetTop 等值，再统一写样式
• ❌ 避免“读-改-读-改”循环：比如在 for 里一边读 el.offsetWidth 一边改 el.style.marginLeft

节流和防抖到底该用哪个？

高频事件（scroll、mousemove、input）不加控制，会持续抢占主线程，导致页面冻结或动画掉帧。但选错策略反而会丢操作或响应迟钝。

• throttle：适合持续触发的场景，比如滚动监听位置、鼠标移动画布。保证每 delay 毫秒最多执行一次，首尾调用要保留（记得配 {leading: true, trailing: true}）
• debounce：适合“等用户停下来再干活”的场景，比如搜索框发请求、resize 后重新计算栅格。最后一次触发后等待 delay 毫秒才执行
• ⚠️ 常见坑：Lodash 的 _.throttle 默认不触发尾调用；自己手写时忘记绑定 this 或透传参数

闭包和事件监听器怎么不偷偷吃内存？

闭包本身不慢，但它会让被引用的对象无法被垃圾回收。一个绑在 window 上的 scroll 回调，如果内部函数捕获了整个 document.querySelector('#huge-list')，那这个列表节点就永远删不掉。

• ✅ 把事件处理逻辑抽成独立命名函数，方便在卸载时用 removeEventListener 清理
• ✅ 用 WeakMap 存私有数据，键是 DOM 节点，值不会阻止节点被回收
• ✅ 定时器、IntersectionObserver、ResizeObserver 用完必须 .disconnect() 或 clearTimeout
• ❌ 避免在回调里直接写箭头函数并引用大对象：el.addEventListener('click', () => doWork(bigData))

哪些任务可以“让出主线程”？

不是所有逻辑都非得立刻跑。日志上报、非关键状态更新、预加载资源……这些完全可以等浏览器空闲时再做，避免打断用户交互或动画帧。

• ✅ 用 requestIdleCallback：只在主线程空闲时调用，且可被中断，适合耗时但不紧急的任务
• ✅ 降级方案：IE 不支持，可用 setTimeout(fn, 0) 或 Promise.resolve().then() 模拟
• ✅ 计算密集型操作（如大数据过滤、JSON 解析）拆成小块，每块后调用 requestIdleCallback 继续
• ⚠️ 注意：它不保证执行时间，也不适合动画或用户可见反馈类逻辑

真正卡顿的根源，常常不在算法多复杂，而在你没意识到某次 offsetTop 读取触发了全页重排，或某个忘了 removeEventListener 的监听器正把整棵树钉在内存里。优化的第一步，是打开 Chrome 的 Performance 面板录一段操作——看到哪条长任务横在那里，就从那里开始切。