4、强制同步布局：什么是强制同步布局、导致布局抖动的常见写法、如何避免

聊到动画掉帧，有一个坑几乎每个前端都踩过，只是很多人没意识到它叫啥。

我记得刚带团队那会儿，有个同事写了个滚动加载的列表，数据量不大，但每次滚动都卡得像幻灯片。我过去一看，代码里每滚动一次就读一次 offsetTop，然后马上改样式。嗯，这就是典型的强制同步布局。

4.1 什么是强制同步布局

先说说浏览器正常的渲染流水线。你写 JavaScript 改样式，浏览器不会立刻去算布局，它会等当前任务执行完，再统一做样式计算、布局、绘制、合成。这叫异步布局，效率很高。

但如果你在修改样式之后，立即读取一个跟布局相关的属性（比如 offsetHeight、clientWidth、getComputedStyle），浏览器就没办法等了。它必须马上把之前的样式变更算完，才能给你一个准确的值。这一下就把异步变成了同步，强制触发了一次完整的布局计算。

说白了，就是你逼浏览器「插队干活」。一次两次还好，动画循环里每帧都这么干，帧率直接崩。

4.2 导致布局抖动的常见写法

我在项目中见过最多的几种写法，给大家列一下：

场景	问题代码	后果
循环读 offsetTop	el.style.top = i + 'px'; console.log(el.offsetTop);	每次循环都强制布局
批量改样式后读宽高	el.style.width = '200px'; let w = el.clientWidth;	一次读取触发一次布局
getComputedStyle 紧跟在样式修改后	el.style.transform = 'translateX(100px)'; getComputedStyle(el).transform;	强制计算样式+布局
requestAnimationFrame 内读写交替	写样式 → 读布局 → 再写样式 → 再读布局	每帧多次强制布局

你想想看，一个动画循环里如果出现这种读写交替，浏览器每帧要被迫做多次布局计算。60fps 的帧率，每帧只有 16.7ms，光布局就占掉一大半，哪还有时间做绘制和合成？

4.3 如何避免强制同步布局

避免的方法其实就一条核心原则：读写分离。把所有读布局的操作集中到一块，所有写样式的操作集中到另一块，中间不要穿插。

我个人的习惯是这样：

1. 先读后写：在 requestAnimationFrame 回调开头，先把所有需要读的布局属性一次性读完，存到变量里。
2. 批量写：读完后再统一修改样式，或者用 classList 切换类名，让浏览器自己合并。
3. 用 transform 代替 top/left：transform 只触发合成，不触发布局，性能好得多。

看个对比：

// ❌ 强制同步布局 —— 读写交替
function badAnimation() {
  for (let i = 0; i < boxes.length; i++) {
    boxes[i].style.left = i * 10 + 'px';
    console.log(boxes[i].offsetLeft); // 每次循环都强制布局
  }
}

// ✅ 读写分离 —— 先读后写
function goodAnimation() {
  // 第一步：集中读取
  const positions = boxes.map(box => box.getBoundingClientRect().left);
  
  // 第二步：集中写入
  boxes.forEach((box, i) => {
    box.style.transform = `translateX(${positions[i] + 10}px)`;
  });
}

你看，第二种写法里，读和写完全分开。浏览器只需要在读取阶段做一次布局，写入阶段再触发一次，不会出现反复强制布局的情况。

4.4 知识体系图

下面这张图把强制同步布局的来龙去脉串起来了：

4.5 实战避坑清单

最后，我把自己踩过的坑整理成一份清单，你写代码的时候可以对照着检查：

• 不要在循环里读写交替 —— 把读操作提到循环外面，或者用 map 先收集再统一写。
• 不要在 rAF 里同时读写 —— 如果必须读，放在回调最前面，写操作放到最后。
• 不要频繁用 getComputedStyle —— 它本身就会触发样式计算，如果前面改过样式，还会触发布局。
• 能用 transform 就别用 top/left/width/height —— 前者只走合成线程，后者要重新布局。
• 善用 will-change —— 提前告诉浏览器哪些属性会变化，让它做优化，但别滥用。