在浏览器渲染流程中，重排、重绘与回流是三个极易混淆但又直接影响页面流畅度的概念。重排指的是元素几何属性发生变化，浏览器需要重新计算布局；回流其实是重排的另一种称呼，二者在英文语境中对应reflow；重绘则是元素样式改变但不影响布局时，仅重新绘制像素的过程。理解它们的触发条件和性能开销，是前端性能优化的基础。
一、概念厘清：重排、回流与重绘的区别
很多资料把回流和重排分开讲，实际上在规范与主流引擎中，回流（reflow）就是重排（relayout），描述的是同一件事：当DOM元素的尺寸、位置或可见性变化，浏览器必须重新计算部分或全部页面的几何结构。这个过程会向上波及父节点、向下波及子节点，代价很高。
重绘发生在布局稳定之后。比如修改了文字颜色或背景色，元素位置没变，浏览器只需把受影响区域重新画一遍。相比之下，重绘成本远低于重排，因为它跳过了布局计算。但要注意，重排一定会引发重绘，而重绘不一定伴随重排。
下面用一段代码说明两者的触发差异：
// 触发重排（回流）：修改宽度，布局变化
const box = document.getElementById('box');
box.style.width = '200px';
// 仅触发重绘：修改背景色，布局不变
box.style.backgroundColor = 'red';
// 连续读写导致强制同步布局，多次重排
for (let i = 0; i < 10; i++) {
console.log(box.offsetWidth); // 读
box.style.height = (i * 10) + 'px'; // 写
}
二、性能剖析：为什么布局抖动最致命
单纯的重绘，比如 hover 改变按钮颜色，在现代浏览器中通常能维持在每帧数毫秒内，用户几乎无感。但重排尤其是布局抖动（layout thrashing）会让主线程被反复占用。布局抖动指在 JavaScript 中交替进行 DOM 读取和写入，每次读取都强制浏览器提前完成排布，造成一帧内多次重排。
我们用一个简单的对比来观察开销。假设页面有五百个列表项，一种做法是先统一改样式再读尺寸，另一种是在循环里边改边读。后者在低端设备上可能使脚本执行时间从几毫秒升到上百毫秒，直接掉帧。因此，优化核心不是彻底消灭重排，而是减少它的触发次数与范围。
| 操作类型 | 是否重排 | 相对开销 |
|---|---|---|
| 修改 color | 否 | 低 |
| 修改 width | 是 | 高 |
| 循环读写 offsetTop | 多次是 | 极高 |
三、实践对比：最有效的优化方法
面对重排与重绘，社区常提三种思路：批量读写、使用合成层属性、虚拟 DOM 差异更新。批量读写是最直接有效的办法，先把所有写操作收集起来，再用 requestAnimationFrame 统一执行，避免强制同步布局。例如用文档片段（DocumentFragment）在内存中拼装节点，最后一次性挂载。
使用 transform 和 opacity 代替 top、left 等几何属性，可以把变动限制在合成线程，不触发重排。以下示例展示如何用 transform 平移替代布局修改：
/* 不推荐：触发重排 */
.move-old {
position: absolute;
left: 0;
transition: left 0.3s;
}
.move-old.active {
left: 100px;
}
/* 推荐：仅合成，无重排 */
.move-new {
transform: translateX(0);
transition: transform 0.3s;
}
.move-new.active {
transform: translateX(100px);
}
虚拟 DOM 类框架通过差异比对减少真实 DOM 操作，间接压缩重排次数，但本身并非银弹。若差异计算比直接操作还慢，反而适得其反。所以最有效的优化是组合拳：开发期用工具定位布局抖动，运行期合并变更、优先用合成属性。
四、避坑指南与总结
一个常见误区是认为 display:none 到 display:block 的切换一定比重绘慢。其实隐藏时元素脱离渲染树，后续显示才重排，若批量处理影响并不大。反而频繁切换 visibility 看似轻量，却可能因层级变化引发意外重绘。建议用性能面板录制交互，看清每一帧的渲染耗时。
总体而言，没有单一方法能通吃所有场景。重绘无法避免但可以最小化，重排应当通过批量与离屏手段削减。认清回流即重排的本质，把几何变动关进合成层的笼子，才是提升网页性能最务实的路径。
reflowrepaintlayout_thrashing修改时间：2026-08-08 15:15:28