offsetWidth、scrollTop等属性会强制同步布局，因浏览器需立即执行完整回流以返回精确值；频繁“读—改—读”将拆分回流、放大性能损耗；应读写分离、缓存尺寸、优先使用transform和ResizeObserver。
修改 offsetWidth 或 scrollTop 这类属性会立刻触发强制同步布局（forced synchronous layout），本质是浏览器为保证返回值准确，必须中断当前渲染流水线、清空样式与布局队列、立即执行一次完整回流——哪怕此时 DOM 变更尚未提交到渲染树。
为什么这些属性如此“危险”
浏览器采用异步渲染策略：样式变更（如 element.style.width = '200px'）通常被暂存于队列中，等到下一帧统一 Layout → Paint。但当你读取 offsetWidth、clientHeight、scrollTop、getComputedStyle() 等属性时，浏览器无法返回“可能过期”的值，必须立刻：
- 应用所有待处理的样式变更
- 递归计算该元素及其祖先/后代的几何信息（包括行高、换行、浮动影响等）
- 完成整个子树的 Layout（即 Reflow）
- 再返回你请求的精确像素值
一次读取可能引发多次回流
常见反模式是“读—改—读—改”循环：
-
el.offsetWidth→ 触发回流 A -
el.style.width = '300px'→ 排队待处理 -
el.offsetHeight→ 再次触发回流 B（因上一步 width 未生效，必须重算）
这相当于把本可合并的一次回流，硬拆成两次，且中间夹杂无意义的计算。实测在中低端移动设备上，连续读取 3 次 offset 属性，性能损耗可达单次回流的 2.7 倍以上。
哪些操作会隐式触发同步布局
除显式读取外，以下行为同样危险：
- 调用
getComputedStyle(el)（即使只取 color，也会全量计算布局） - 访问
el.scrollHeight/el.scrollWidth（需确定内容实际尺寸） - 使用
el.getBoundingClientRect()（依赖精确位置与尺寸） - 在
resize或scroll事件中频繁读取视口或元素尺寸
真正有效的规避方式
核心原则：读写分离，批量处理，避免跨帧查询。
- 把所有读操作集中放在最前面，缓存结果（如先读
offsetWidth和offsetTop，再统一写样式） - 用
transform或opacity替代位置/尺寸变更（它们走合成层，不触发回流） - 对需要频繁测量的元素，用
ResizeObserver替代监听window.resize+ 手动查offset - 动画场景中，用
requestAnimationFrame包裹读操作，并确保同一帧内不混入写操作
