3. 布局与重排优化：触发重排的常见操作、使用 CSS containment 隔离渲染、利用 will-change 提前告知浏览器、实战：减少布局抖动
说到页面流畅度，重排（Reflow）绝对是头号杀手。我见过太多项目，明明代码逻辑没问题，动画就是卡顿，滚动就是掉帧。追根溯源，十有八九是布局抖动在作祟。
这一节，咱们就彻底把重排这件事掰开揉碎。我会从最基础的触发条件讲起，再到 CSS containment 和 will-change 这两个利器，最后用一个实战案例把知识串起来。
3.1 触发重排的常见操作
先问一个问题：浏览器什么时候会重新计算布局？
说白了，只要 DOM 的几何属性发生变化，或者某些 CSS 属性被读取时触发了同步计算，浏览器就得重新走一遍布局流程。我整理了一份清单，这些都是日常开发中最容易踩的坑：
| 操作类型 | 具体行为 | 影响范围 |
|---|---|---|
| 尺寸变化 | 修改 width、height、padding、margin、border | 自身 + 子元素 + 后续兄弟元素 |
| 位置变化 | 修改 top、left、right、bottom、float、position | 自身 + 兄弟元素 + 父容器 |
| 内容变化 | 文本增减、图片加载、字体替换 | 自身 + 父容器 + 相邻元素 |
| 读取布局属性 | 读取 offsetTop、offsetHeight、getBoundingClientRect() 等 | 强制同步布局（Forced Reflow） |
| DOM 操作 | 增删节点、修改 class、切换 display | 视具体结构而定 |
我记得有一次接手一个老项目，页面里有个表格，每次筛选数据都要卡两三秒。查了半天，发现是筛选函数里写了这样的代码：
// 错误示范：每次循环都触发强制同步布局
for (let i = 0; i < items.length; i++) {
element.style.height = items[i].height + 'px';
console.log(element.offsetHeight); // 这里触发了重排！
}
改起来其实很简单：把读写操作分开，先批量写，再批量读。或者用 requestAnimationFrame 把读操作延后一帧。
3.2 使用 CSS containment 隔离渲染
CSS containment 是个好东西，但很多人不知道。它的核心思想是：告诉浏览器，某个元素内部的渲染变化不会影响到外部，这样浏览器就可以把重排范围限制在这个元素内部，不用整棵树重新算。
我个人习惯在以下场景使用 containment：
- 独立组件：比如弹窗、下拉菜单、侧边栏
- 虚拟列表：每个列表项都是独立的渲染单元
- 动画容器：动画只影响容器内部，不影响外部布局
常用的 containment 值有这几个：
| 属性值 | 作用 | 适用场景 |
|---|---|---|
contain: layout |
内部布局变化不影响外部 | 独立组件、弹窗 |
contain: paint |
内部绘制不溢出边界 | 固定尺寸容器 |
contain: size |
元素尺寸由显式宽高决定，不受子元素影响 | 已知尺寸的容器 |
contain: strict |
同时启用 layout、paint、size | 完全隔离的组件 |
contain: content |
同时启用 layout、paint | 大多数场景 |
contain: content。它覆盖了 layout 和 paint，对大部分独立组件都够用。只有当你明确知道子元素尺寸不会影响父容器时，才考虑加 size。
来看一个实际例子。假设我们有一个聊天列表，每条消息都是一个独立组件：
.chat-message {
contain: content;
/* 消息内部的布局变化不会影响外部列表 */
}
这样，当某条消息内部有动画或者内容变化时，浏览器只需要重排这条消息本身，不会波及整个列表。在长列表场景下，性能提升非常明显。
3.3 利用 will-change 提前告知浏览器
will-change 这个属性，说白了就是给浏览器打预防针。你提前告诉它：「嘿，这个元素接下来要变了，你先准备一下。」
浏览器收到这个信号后，会提前为该元素创建独立的渲染层，把该元素从常规的渲染流程中抽离出来。这样当变化真正发生时，就不需要重新走一遍完整的布局和绘制流程了。
但这里有个坑——不要滥用。我曾经见过有人给页面上所有元素都加了 will-change: transform，结果页面反而更卡了。为什么？因为每个元素都创建独立层，GPU 内存被撑爆了。
正确的用法是：
- 只在即将变化的元素上使用，变化结束后移除
- 用 JavaScript 动态控制，而不是写死在 CSS 里
- 优先用于 transform 和 opacity，这两个属性变化不会触发重排
// 推荐做法：动画开始前添加，结束后移除
const element = document.querySelector('.animated-card');
element.addEventListener('mouseenter', () => {
element.style.willChange = 'transform';
});
element.addEventListener('animationend', () => {
element.style.willChange = 'auto';
});
will-change: transform 然后就不管了。这样等于让浏览器一直为这个元素保留独立层，浪费内存。我曾经在一个后台管理系统里发现，就因为一个弹窗的 will-change 没清理，导致页面在低端手机上频繁闪退。
3.4 实战：减少布局抖动
布局抖动（Layout Thrashing）是什么？就是在一段连续代码里，反复读写 DOM 布局属性，导致浏览器被迫多次执行重排。这是性能优化的重灾区。
来看一个我实际重构过的案例。一个图片瀑布流布局，需要根据每张图片的高度动态计算位置：
// ❌ 抖动版本：每次循环都触发重排
function layoutMasonry(items) {
for (let i = 0; i < items.length; i++) {
const item = items[i];
item.style.width = '200px';
// 下面这行读取 offsetHeight，强制同步布局
const height = item.offsetHeight;
item.style.top = calculateTop(height, i);
}
}
这个版本的问题在于：每次循环都先写 width，再读 offsetHeight。浏览器为了给你准确的高度，不得不立即执行一次重排。如果 items 有 100 个，那就重排 100 次。
优化后的版本：
// ✅ 优化版本：读写分离，批量操作
function layoutMasonry(items) {
// 第一步：批量写
for (let i = 0; i < items.length; i++) {
items[i].style.width = '200px';
}
// 第二步：批量读（此时浏览器已经完成一次重排）
const heights = [];
for (let i = 0; i < items.length; i++) {
heights.push(items[i].offsetHeight);
}
// 第三步：批量写位置
for (let i = 0; i < items.length; i++) {
items[i].style.top = calculateTop(heights[i], i) + 'px';
}
}
这样，无论有多少个元素，浏览器最多只重排两次。性能差距在数据量大时非常明显。
下面这张图展示了布局抖动的核心问题：
除了读写分离，还有几个实用技巧：
- 使用文档片段：批量插入 DOM 时，先用 DocumentFragment 组装，再一次性插入
- 隐藏元素再操作：对复杂元素先设
display: none，操作完再显示 - 使用 transform 代替 top/left：transform 不会触发重排，只触发合成
- 避免 table 布局：table 的布局计算成本远高于块级布局
- 重排是性能杀手，读写分离是基本功
- CSS containment 可以隔离渲染范围，减少重排波及面
- will-change 要动态使用，用完即弃
- 能用 transform 和 opacity 实现的动画，绝不动布局属性
嗯，这一节的内容就到这里。布局优化是个细活，但只要你掌握了这些原则，大部分性能问题都能迎刃而解。下次遇到页面卡顿，先别急着怀疑框架，打开 DevTools 看看 Performance 面板，十有八九能找到布局抖动的痕迹。