JavaScript性能优化全攻略

JavaScript性能优化的核心在于精准识别并消除那些看似微小却足以拖垮体验的“隐形杀手”：一次不经意的DOM读写触发全页重排、一个未清理的事件监听器长期霸占内存、高频滚动中失控的回调挤占主线程，或是本可延后的任务强行抢占动画帧——真正有效的优化往往就藏在日常代码的细节里，而掌握批量DOM操作、合理选用节流/防抖、规避闭包内存泄漏、善用requestIdleCallback让出主线程等关键技巧，能让你从被动救火转向主动掌控性能命脉。

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

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

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

• ✅ 用 DocumentFragment：先把节点建在内存里，最后一次性挂载
• ✅ 用 innerHTML 或 cssText 批量写入样式，别逐个设 style.color、style.fontSize
• ✅ 读写分离：先集中读完所有 getBoundingClientRect()、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 面板录一段操作——看到哪条长任务横在那里，就从那里开始切。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《JavaScript性能优化全攻略》文章吧，也可关注golang学习网公众号了解相关技术文章。