什么是 Layout Thrashing？

引子：一段”看起来没问题”的代码

假设你需要给页面上的一组元素动态设置宽度，让它们和某个参考元素保持一致。很多人会写出这样的代码：

const boxes = document.querySelectorAll('.box');
const referenceWidth = reference.offsetWidth;

boxes.forEach((box) => {
  box.style.width = referenceWidth + 'px';
});

这段代码功能上没有任何问题，但如果把它稍微改一下——比如在循环里既读又写：

boxes.forEach((box) => {
  const width = reference.offsetWidth; // 读
  box.style.width = width + 'px';       // 写
});

在元素数量较多时，页面可能会明显卡顿。问题就出在这里：Layout Thrashing（布局抖动）。

一、浏览器渲染的基本流程

要理解 Layout Thrashing，得先简单回顾一下浏览器的渲染管线。当 DOM 或样式发生变化后，浏览器大致会经历以下几个阶段：

Recalculate Style（样式计算）：确定每个元素最终应用的 CSS 规则。
Layout（布局，也叫 Reflow）：根据样式计算元素在页面中的几何信息——位置、宽高等。
Paint（绘制）：把元素的视觉样式（颜色、阴影、边框等）绘制成位图。
Composite（合成）：将各个绘制层按顺序合成为最终画面。

这几个阶段中，Layout 是开销较大的一环，因为它往往牵一发而动全身：一个元素的尺寸变化，可能影响其兄弟元素、父元素乃至整个文档的布局，浏览器需要重新计算受影响的所有几何信息。

正因为代价高，浏览器做了一个重要的优化：把多次样式修改攒起来，合并成一次布局计算，而不是修改一次就重新布局一次。这个优化通常发生在一次事件循环（或一帧）结束时统一执行。

二、Layout Thrashing 究竟是什么

Layout Thrashing 指的是：在同一段代码中反复交替进行”写入样式”和”读取会触发强制布局的属性”，导致浏览器的批量优化失效，被迫连续多次同步执行布局计算。

关键在于”读取”这个动作。浏览器提供了一些属性和方法，只要访问它们，浏览器就必须保证返回的是最新、准确的几何信息。如果此时还有未应用的样式修改在”排队”，浏览器就不能偷懒——它必须立刻把这些排队的修改应用上去,并同步执行一次布局计算，这个过程称为强制同步布局（Forced Synchronous Layout），也常被称为 Layout Thrashing 的直接触发动作。

回到开头的例子：

boxes.forEach((box) => {
  const width = reference.offsetWidth; // 读取，触发强制布局
  box.style.width = width + 'px';       // 写入，使布局失效
});

假设有 100 个元素，每一次循环都会：

读取 offsetWidth → 如果上一轮写入导致布局失效，浏览器必须立刻重新计算布局才能给出准确值；
写入 style.width → 让当前布局重新变为”失效”状态。

于是这 100 次循环会触发多达上百次的同步布局计算，而不是浏览器本可以合并成的一次。这就是”抖动”（Thrashing）这个名字的由来——布局状态在”有效”和”失效”之间被反复来回折腾。

三、哪些操作会触发强制布局

并不是所有的属性读取都会引发问题，只有那些依赖最新几何信息的属性才会。常见的”雷区”属性和方法包括：

尺寸类：offsetWidth、offsetHeight、offsetTop、offsetLeft
滚动类：scrollWidth、scrollHeight、scrollTop
客户端区域类：clientWidth、clientHeight、clientTop
布局方法：getComputedStyle()、getBoundingClientRect()
部分场景下的 focus() 调用等

只要在修改样式之后紧接着读取这些属性，就有可能触发强制同步布局。而如果修改和读取是分开进行、互不交替的,浏览器就有机会把所有修改合并处理,只做一次布局计算。

四、如何避免 Layout Thrashing

理解了成因,解决思路就很清晰:把”读”和”写”分离,避免交替进行。常见的做法有以下几种。

1. 批量读取,再批量写入

最直接的优化方式,是先把所有需要的几何信息一次性读完,存到变量里,再统一进行样式修改:

const boxes = document.querySelectorAll('.box');
const referenceWidth = reference.offsetWidth; // 只读一次

boxes.forEach((box) => {
  box.style.width = referenceWidth + 'px'; // 集中写
});

这样读操作和写操作不再交替,浏览器可以把所有写入合并成一次布局。

2. 使用 DocumentFragment 或离屏节点

如果需要对一个节点进行多次结构性修改(增删子元素等),可以先在内存中的 DocumentFragment 或被 display: none 隐藏的节点上操作,完成后再一次性插入或显示到页面中,避免每次修改都影响可见的渲染树。

3. 借助 `requestAnimationFrame` 调度读写时机

对于需要在动画中频繁读取布局信息的场景,可以把”读”和”写”分别安排到不同的帧,或者利用 requestAnimationFrame 的调用时机来做统一调度,减少读写交替的机会。一些工具库(如 fastdom)就是基于这个思路,自动把同一批任务中的读操作和写操作分组执行。

4. 用 CSS 变换代替触发布局的属性

在做动画时,优先使用 transform 和 opacity 这类只影响合成阶段、不触发布局和重绘的属性,而不是直接修改 top、left、width、height 等几何属性。这从源头上减少了布局计算的必要性。

五、如何定位 Layout Thrashing 问题

Chrome DevTools 的 Performance 面板是排查此类问题的利器。录制一段操作后,如果在时间线上看到大量密集的紫色 Layout 色块,并且控制台提示 “Forced reflow”、”Forced synchronous layout” 等字样,就说明代码中存在读写交替的问题,可以结合调用栈定位到具体的代码位置。