4. Layout Thrashing：强制同步布局的成因与检测

布局抖动，英文叫 Layout Thrashing。这词听起来挺吓人，说白了就是——浏览器被迫反复做布局计算。

我刚开始接触前端性能时，总觉得页面卡顿是 JS 执行太慢。后来有一次，我花了两天时间排查一个列表滚动卡死的问题，最后发现罪魁祸首就是一段看似无害的循环代码。嗯，从那以后，我对「读写分离」这四个字有了刻骨铭心的理解。

4.1 什么是强制同步布局？

先看一个正常流程。浏览器渲染一帧时，会按顺序走：JavaScript → Style → Layout → Paint → Composite。这个顺序是异步的，JS 执行完，浏览器自己决定什么时候做布局。

但如果你在 JS 里干了这么一件事——先写样式，再立刻读布局属性——浏览器就没办法了。它必须暂停 JS，立刻执行一次布局计算，才能把正确的值返回给你。这就是「强制同步布局」（Forced Synchronous Layout）。

举个例子，你写了个循环，每轮都做「写 + 读」：

// ❌ 典型 Layout Thrashing
const boxes = document.querySelectorAll('.box');
for (let i = 0; i < boxes.length; i++) {
  boxes[i].style.width = `${i * 10}px`;   // 写
  const height = boxes[i].offsetHeight;    // 读 → 强制布局
  boxes[i].style.height = `${height}px`;   // 再写
}

这段代码每循环一次，浏览器就做一次布局。100 个元素就是 100 次布局。你想想看，一帧只有 16ms，光布局就占满了，能不卡吗？

4.2 哪些属性会触发强制同步布局？

不是所有属性都会。只有那些需要实时计算的布局属性才会。我习惯把它们分成两类：

类别	属性列表
尺寸相关	offsetWidth、offsetHeight、clientWidth、clientHeight、scrollWidth、scrollHeight
位置相关	offsetTop、offsetLeft、scrollTop、scrollLeft、getBoundingClientRect()、getComputedStyle()

4.3 如何检测 Layout Thrashing？

检测方法有三种，我按推荐程度排个序：

1. Chrome DevTools Performance 面板：录制一段操作，看「Layout」事件是否密集出现。如果 Layout 事件紧跟在 JS 执行后面，且没有明显的间隔，基本就是强制同步布局。
2. Rendering 面板的「Layout Shift Regions」：打开 DevTools → Rendering → 勾选「Layout Shift Regions」，页面中会高亮显示发生布局抖动的区域。
3. 代码静态分析：手动检查循环中是否存在「写后读」模式。这个最原始，但也最直接。

我个人习惯用第一种。打开 Performance 面板，点录制，操作几下，然后看火焰图。如果看到一串紫色的「Layout」事件，像糖葫芦一样串在一起，那基本就中招了。

4.4 修复策略：读写分离

修复 Layout Thrashing 的核心思路就四个字：读写分离。

把所有「写」操作集中在一起，所有「读」操作集中在一起。浏览器只需要做一次布局，就能满足所有读取需求。

// ✅ 读写分离
const boxes = document.querySelectorAll('.box');
const heights = [];

// 第一阶段：批量读取
for (let i = 0; i < boxes.length; i++) {
  heights.push(boxes[i].offsetHeight);
}

// 第二阶段：批量写入
for (let i = 0; i < boxes.length; i++) {
  boxes[i].style.width = `${i * 10}px`;
  boxes[i].style.height = `${heights[i]}px`;
}

你看，这样改完之后，布局只发生一次。100 个元素，从 100 次布局降到 1 次，性能差距是数量级的。

4.5 一个真实案例

我曾经接手过一个表格组件，每次滚动都卡得不行。排查后发现，代码里有一个 onScroll 事件，每次触发都会读取 getBoundingClientRect()，然后设置某个元素的 transform。滚动一快，每秒触发 60 次，每次触发都强制布局一次。

修复方案很简单：

1. 把 getBoundingClientRect() 的读取结果缓存起来，只在滚动停止时更新。
2. 用 transform 代替 top/left 做位移，因为 transform 不会触发布局。

改完之后，滚动帧率从 15fps 直接升到 60fps。嗯，有时候性能优化就是这么「简单」——找到那个不该存在的强制布局，干掉它。

4.6 知识体系图

下面这张图总结了 Layout Thrashing 的完整链路：从触发条件到检测手段，再到修复策略。

4.7 避坑指南

最后分享几个我踩过的坑：

• 别在 resize 事件里读布局属性：resize 触发频率极高，每次读布局都是灾难。用防抖或节流，或者干脆缓存。
• 动画循环里别读 offsetTop：如果你用 requestAnimationFrame 做动画，里面只写不读。读的话，一帧变两帧的活。
• 第三方库也可能引发 Layout Thrashing：我曾经用过一个老版本的图表库，内部实现里有个循环读写。排查了半天才发现不是自己的锅。遇到这种情况，要么换库，要么给库打补丁。