优化策略与最佳实践

理解了重排和重绘的触发条件及其性能影响后，目标就变得清晰：尽量减少重排的次数，缩小重排的影响范围，将重排与重绘的代价降到最低。下面这些策略都是经过大量实践验证的，你可以放心地在日常开发中使用。

批量操作 DOM

每次对 DOM 的单独修改都可能触发一次重排，因此第一个原则是“攒一批，一起改”。

使用文档片段（DocumentFragment）

在内存中构建一个离线的 DOM 子树，全部组装完成后再一次性挂到页面上。整个过程只触发一次重排。

  const fragment = document.createDocumentFragment();
  for (let i = 0; i < 100; i++) {
    const li = document.createElement('li');
    li.textContent = `Item ${i}`;
    fragment.appendChild(li);
  }
  document.querySelector('ul').appendChild(fragment);

操作 display: none 的元素

将元素先设为 display: none（此时它脱离渲染树，任何对它的修改都不会引发重排），在隐藏状态下完成 DOM 操作，最后再让它显示。

  const container = document.querySelector('.box');
  container.style.display = 'none';
  // 执行大量 DOM 变更
  container.style.width = '200px';
  // ...
  container.style.display = 'block';

拷贝节点，离线处理

使用 cloneNode() 复制一个节点，修改完毕后再替换原节点。

合并多次样式修改

连续多次修改元素的样式属性，浏览器会分别触发重排。将它们合并成一次修改，就能有效减少计算。

用 classList 切换类名，而非直接修改行内样式

将需要改动的样式集中定义在一个 CSS 类中，JavaScript 只负责切换这个类。这样浏览器只需要计算一次样式差异。

  element.classList.add('active');  // 所有样式变更都在 active 类中定义

用 cssText 一次性批量设置行内样式

如果必须动态计算样式，也可以将多个样式属性拼成一条字符串，通过 style.cssText 一次性赋值。

  element.style.cssText = 'width: 200px; height: 100px; background: red;';

避免逐个读取布局属性

这是一个容易被忽视的陷阱：如果在修改样式的同时又去读取某些布局信息（如 offsetWidth、clientHeight、scrollTop 等），浏览器为了返回准确的值，会强制同步执行一次重排，导致多次重排。
先批量读取，再批量写入，分离读写操作。

  // ❌ 混合读写会导致强制同步重排
  element.style.width = '200px';
  const h = element.offsetHeight;   // 读，强制重排
  element.style.height = h * 2 + 'px';

  // ✅ 先读后写
  const h = element.offsetHeight;  // 读取
  element.style.width = '200px';   // 写入
  element.style.height = h * 2 + 'px'; // 写入，在上次重排后的同一帧内合并

利用绝对定位脱离文档流

如果一个元素会频繁地独立重排（如动画、拖拽操作），可以将它的 position 设为 fixed 或 absolute。这样它的重排只会影响自身，不会导致父元素或相邻元素的重排，重排的代价大幅降低。

使用 CSS 动画代替 JavaScript 动画

CSS 动画（transition、animation）由浏览器的合成器线程处理，不会触发主线程的重排或重绘（前提是只改变 transform 和 opacity 这两个属性）。这也是现代高性能动画的核心思想。

.box {
  transition: transform 0.3s ease;
}
.box:hover {
  transform: translateX(100px); /* 不触发重排，直接在合成层完成 */
}

对复杂的布局计算使用 `requestAnimationFrame`

需要基于当前布局状态计算下一帧的样式变化时，将计算和样式更新放在 requestAnimationFrame 回调中。这能确保在每一帧的合适时机执行，避免不必要的重复重排。

requestAnimationFrame(() => {
  element.style.transform = `translateX(${scrollTop}px)`;
});

启用 GPU 合成层

将经常变化的元素提升为独立的合成层，可以让它的变化完全在 GPU 上处理，完全不打扰主线程的布局和绘制。常用方法包括：

使用 will-change 提示浏览器

  .animated-element {
    will-change: transform;
  }

注意：will-change 不应滥用，只对需要频繁变化的元素使用，且使用后记得及时移除，以免占用过多资源。

使用 3D 变形强制创建合成层

  .element {
    transform: translateZ(0); /* 即使不进行 3D 变换，也能触发合成层 */
  }

控制重排作用域

position: fixed / absolute 已经提过可以缩小重排范围。另一个方法是使用 contain 属性（CSS Containment），显式告诉浏览器某个子树的布局变化不会影响外部，从而让浏览器的优化边界更清晰。

避免使用表格布局

表格（<table>）内部任何一个单元格的尺寸变化，都可能导致整个表格自上而下、自左而右地重新计算布局，重排代价极高。在性能敏感的场景下，尽量用其他布局方式替代。

实践检查清单

当你怀疑一个页面存在性能问题时，可以基于下面几条自查：

是否在循环或高频回调中一次又一次地读取布局属性（如 offsetWidth）后又写入样式？
是否在 scroll、resize 等高频事件中直接修改 DOM？——别忘了使用防抖或节流，或者交给 requestAnimationFrame 处理。
动画是否只改变了 transform 和 opacity？
是否在创建大量动态节点时忘记使用文档片段或 display: none 隔离？
是否忘记了合理的布局策略，让一个小组件的变化引发了整个页面的重排？

掌握这些优化思路，你就能在遇到性能瓶颈时快速定位问题，并给出有针对性的修复方案。在开发中养成“先思考布局影响”的习惯，往往能事半功倍。