优化JS性能，减少重绘重排技巧

本文深入剖析了前端性能优化中极易被忽视却影响深远的关键问题——重排（reflow）与重绘（repaint）的代价差异，明确指出重排因需重新计算几何布局并影响渲染树而远比重绘昂贵；文章系统揭示了强制同步布局、频繁DOM操作、不当动画属性等常见性能陷阱，并给出切实可行的解决方案：通过读写分离避免同步布局、优先使用transform/opacity实现硬件加速动画、借助DocumentFragment批量操作DOM，以及在滚动/缩放场景中合理节流布局读取——这些技巧直击现代Web应用卡顿根源，助你写出更流畅、更高效的JavaScript代码。

重排（reflow）和重绘（repaint）到底谁更贵

重排一定触发重绘，但重绘不一定触发重排。真正吃性能的是重排——它需要重新计算元素的几何属性（位置、尺寸），并影响整个渲染树中相关节点。比如修改 offsetTop、clientWidth，或任何会读取布局信息的操作，都可能强制浏览器立即执行一次重排。

• 常见触发重排的操作：offsetLeft、getComputedStyle()（读取某些属性时）、scrollTo()、改变 className 或内联 style 中影响盒模型的属性（如 width、padding、display）
• 只触发重绘的操作：修改 color、background-color、visibility（注意不是 display: none）等不改变几何信息的样式
• 现代浏览器会批量处理样式修改，但一旦你读取布局信息（如 offsetHeight），就会打破队列，强制同步重排

批量读写分离：避免 forced synchronous layout

所谓“强制同步布局”，就是你在 JS 中一边改样式一边立刻读取尺寸，导致浏览器不得不中断当前渲染流程，立刻计算并返回结果。这是最常被忽视的性能杀手。

• ❌ 错误写法：

  element.style.height = '200px';
  console.log(element.offsetHeight); // 强制重排

• ✅ 正确做法：先批量读、再批量写，或用 getBoundingClientRect() 替代多次读取
• 更稳妥的方式是把读操作全部前置，写操作全部后置；或者使用 requestAnimationFrame() 把写操作推迟到下帧开始前

用 transform 和 opacity 做动画替代 top/left/width

只要元素开启了硬件加速（例如有 transform: translateZ(0) 或 will-change: transform），浏览器会把它提升为独立图层，后续对 transform 和 opacity 的修改就只触发合成（composite），完全跳过重排和重绘。

• ❌ 避免：top、left、width、height 动画（每次修改都重排）
• ✅ 推荐：transform: translateX(100px)、transform: scale(1.2)、opacity: 0.5
• will-change 不要滥用：只在动画开始前设置，动画结束及时清除，否则长期占用 GPU 内存

DOM 操作尽量少而集中

频繁增删、移动 DOM 节点会反复触发重排。哪怕只是往 document.body 追加 10 个 div，逐个 appendChild() 也会造成 10 次潜在重排。

• 用 DocumentFragment 批量插入：

  const frag = document.createDocumentFragment();
  for (let i = 0; i 

• 隐藏元素再操作：el.style.display = 'none' → 修改 → el.style.display = ''，适用于复杂子树更新
• 避免在循环中访问 innerHTML 或 innerText，它们会触发解析和重排

今天关于《优化JS性能，减少重绘重排技巧》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！