强制同步布局是JavaScript读取元素几何属性时，因布局状态过期而被迫立即执行layout计算的行为；它打断渲染流水线，引发掉帧和抖动。

什么是强制同步布局（Forced Synchronous Layout）？

强制同步布局发生在 JavaScript 读取某个元素的几何属性（如 offsetTop、getBoundingClientRect()、clientWidth）后，浏览器发现布局状态已过期（比如 DOM 刚被修改但未重排），就不得不立即触发 layout 计算——这个“马上就得算”的行为就是强制同步布局。它打断渲染流水线，常导致掉帧和肉眼可见的抖动。

为什么“读写分离”能缓解抖动？

核心不是“分离”本身，而是避免在单次 JS 执行中交替进行“写→读→写→读”。浏览器可以批量处理样式/结构变更（写），但只要中间穿插一次读取布局信息，就会强制刷新 layout 缓存，把后续所有写操作也拖进同步路径。

• ✅ 好模式：先批量写 DOM / class / style → 然后统一读所有需要的尺寸
• ❌ 抖动模式：写一个元素 → 读它的 offsetHeight → 再写下一个 → 再读…
• ⚠️ 注意：requestAnimationFrame 回调里读取仍可能触发强制同步布局，如果此前已有未 flush 的样式变更

实际怎么落地读写分离？

关键不是加个 setTimeout 或 Promise.resolve() 就完事，得确保“读”发生在浏览器完成 layout 之后。最稳妥的是用 requestAnimationFrame + offsetParent 检查或 getComputedStyle 预热，但更推荐以下组合：

• 所有 DOM 写操作（增删节点、改 class、设 style.width）集中放在一次任务中
• 读操作全部推迟到下一次 requestAnimationFrame 的回调开头（此时 layout 已完成，paint 尚未开始）
• 避免在事件处理器里反复读写混用，例如 scroll 中不要一边 el.style.transform = ... 一边又立刻读 el.scrollHeight
• 用 el.getBoundingClientRect() 替代多个 offsetTop + offsetLeft 组合，减少 layout 触发次数

容易被忽略的坑

很多人以为加了 raf 就万事大吉，但仍有几个隐蔽雷区：

• getComputedStyle(el).height 在 el 未插入文档时返回 auto，但也会触发 layout —— 即使你没想要值
• 使用 offsetParent === null 判断是否挂载，比 el.offsetParent 更安全，后者在某些 CSS 下会误判
• CSS 中的 contain: layout 或 content-visibility: auto 可能让部分元素跳过 layout，但读取其尺寸仍会强制计算，别依赖它们“自动优化”
• 框架（如 React）的 useLayoutEffect 里读尺寸仍是同步的，需手动拆成两个 effect：一个只写，一个用 useEffect + raf 读

抖动从来不是单一 API 的问题，而是读写时机与浏览器渲染阶段错位的结果。真正要盯住的，是每个读操作前面最近一次 DOM 写是否已 commit，以及是否被同任务中的其他读打断。