强制同步布局是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，以及是否被同任务中的其他读打断。
