CSS 性能优化：重排与重绘的 6 个真相

重排（reflow，也叫布局 layout）和重绘（repaint）不是"越少越好"的玄学，而是"能攒就攒、能跳过就跳过"的工程问题——真正拖慢页面的往往不是一次重排，而是一帧里被强制算了几十次布局。搞清下面 6 个真相，比死记"别用 table"有用得多。

真相一：重排一定带重绘，重绘不一定带重排

结论：改变几何属性（宽高、位置、内外边距、字体大小、display 等）会触发重排并连带重绘；只改颜色、背景、visibility 这类"外观属性"只触发重绘。

浏览器渲染管线的顺序是：样式计算 → 布局（重排）→ 绘制（重绘）→ 合成。布局一旦变了，绘制结果必然作废，所以重排的成本包含重绘。反过来，只改个 `background-color`，布局结果还能复用，就省掉了最贵的一步。

实用判断法：属性值参与"谁在哪、占多大"的计算，就是重排属性。 所以动画里用 `transform: translate()` 代替 `top/left`，本质是把"改布局"换成"改合成"。

真相二：一次重排不贵，一帧里被强制算几十次才贵

这是最关键的一条。浏览器的策略是"攒批"：你连着改 5 个元素的 `style.width`，它会在下一帧统一算一次布局。但只要你中间插入一次"读操作"，浏览器就必须立刻把积压的布局算完，才能给你准确的数值——这叫强制同步布局（forced synchronous layout）。

会强制刷新的读操作包括：`offsetTop / offsetLeft / offsetWidth / offsetHeight`、`scrollTop / scrollLeft`、`getBoundingClientRect()`、`getComputedStyle()`、`clientWidth` 等。

// ❌ 读写交替：每次循环触发一次强制布局
for (const el of items) {
  el.style.width = el.offsetWidth + 10 + 'px';
}

// ✅ 读写分离：先全部读出来，再全部写回去
const widths = items.map(el => el.offsetWidth);
items.forEach((el, i) => { el.style.width = widths[i] + 10 + 'px'; });

结论：**优化重排的第一优先级不是"减少重排属性"，而是消灭读写交替（layout thrashing）。** 打开 DevTools 的 Performance 面板录一段，如果看到密密麻麻的紫色 Layout 块挤在一帧里，基本就是这个问题。

真相三：transform 和 opacity 也可能翻车

结论：`transform` / `opacity` 动画之所以流畅，是因为它们能被提升到独立合成层，跳过布局和绘制；但层不是免费的，滥用 `will-change` 或给大量元素加 `translateZ(0)` 会爆显存，反而更卡。

正确姿势是：只在动画即将开始前加 `will-change: transform`，动画结束就移除；不要写进长期生效的 CSS 里。同时注意，`transform` 改变的是视觉呈现，元素的实际占位不变——如果你需要"挪动后让出空间"，它帮不了你，该重排还是得重排。

另外，层级提升后如果层内内容发生变化，依然会重绘，只是不影响兄弟元素。

真相四：改一次 class，胜过改十个 style

结论：连续设置多个内联样式，即便浏览器会合并，也容易在中间被读操作打断；用 `classList` 一次性切换类名，让浏览器只做一次样式计算，是最稳的写法。

// ❌ 多次触发样式重算
el.style.width = '200px';
el.style.height = '100px';
el.style.backgroundColor = '#f00';

// ✅ 一次搞定
el.classList.add('card-expanded');

同理，批量插入 DOM 时不要在循环里反复 `appendChild`。用 `DocumentFragment` 先离线拼装，或对容器先 `display: none` 再操作，最后一次插入/显示，这样只产生一次布局。

真相五：重绘成本看"面积 × 复杂度"，不是元素个数

很多人以为元素越多重绘越慢，其实不然。绘制成本主要由三个因素决定：重绘区域的像素面积、绘制指令的复杂度、以及是否落在独立图层上。

代价最高的几类 CSS 效果：大面积 `box-shadow`（尤其是模糊半径大的）、`filter: blur()`、`border-radius` 配合裁剪、大面积半透明叠加。一个占满屏幕的模糊阴影，比 500 个小图标的重绘代价高得多。

调试手段：DevTools → Rendering 面板勾选 Paint flashing，重绘区域会闪绿光。你一眼就能看出是哪块"大面积"在反复刷。

想进一步隔离影响范围，可以给独立的滚动容器或卡片加 `contain: layout paint;`，告诉浏览器"这块内部的布局和绘制不会影响外面"，把重排的传播范围掐断。

真相六：先测量，再优化，别凭感觉改

结论：CSS 性能问题必须用数据定位，主观猜测改出来的"优化"经常是负收益。

标准流程是三步：① Performance 面板录制一段包含问题操作的交互，看 Layout / Recalculate Style / Paint 各自的耗时占比；② 锁定是"次数问题"还是"面积问题"；③ 只改对应那一项，改完再录一次做前后对比。

如果 Layout 块多而碎，去查读写交替；如果单次 Paint 特别粗，去查阴影、模糊和大面积动画。方向对了，改动通常只有几行。

收个尾：能合并的写操作合并（改 class、DocumentFragment），能延后的读操作延后（读写分离 + `requestAnimationFrame`），能跳过的绘制就跳过（`transform` / `opacity` + 谨慎的合成层），能隔离的范围就隔离（`contain`）。这四件事做完，绝大多数页面的滚动和动画卡顿就消失了。