“读写分离”不能彻底消除强制同步布局，但能将其收敛至最少、最可控的一次；关键在于先批量读取offsettop、getboundingclientrect等触发layout的属性，再集中执行样式修改，避免读写穿插导致缓存失效和反复重排。
“读写分离”不能彻底消除强制同步布局，但能把它压缩到最少、最可控的一次——关键不是消灭 layout，而是不让它反复发生。
哪些操作属于“读”且会强制触发 layout
只要浏览器当前样式未更新（比如刚执行完 JS 但还没进入渲染帧），读取以下任一属性就会立刻 flush style + layout：
- offsetTop / offsetLeft / offsetWidth / offsetHeight
- clientTop / clientLeft / clientWidth / clientHeight
- scrollWidth / scrollHeight / scrollTop / scrollLeft
- getBoundingClientRect()（最典型高危操作）
- getComputedStyle(el).width、.height、.top 等依赖布局的字段
注意：className、textContent、style.color 这类纯写或不依赖布局的读取，完全安全。
为什么“先读后写”必须严格分块
浏览器对连续读取同一元素的 layout 属性有一定缓存（layout cache），但一旦中间穿插了任何样式修改（如 el.style.width = '200px'），缓存就失效——下一次读又得重新 layout。
错误模式（抖动根源）：
for (let i = 0; i <p>正确做法（只 layout 一次）：</p> <pre class="brush:php;toolbar:false;">// ✅ 批量读 const heights = []; for (let i = 0; i <h3>在滚动/动画等高频场景中落地读写分离</h3> <p>scroll、resize、mousewheel 等事件里直接读写混用，是帧率跌破 30fps 的常见原因。稳妥做法是：</p>
- 用 requestAnimationFrame 包裹读操作（确保在 layout 完成后读）
- 把写操作放到下一个 raf 回调开头（让浏览器把所有写批量推迟到 paint 前）
- 优先使用 transform 和 opacity 动画，它们走合成线程，不触发布局
- 对频繁定位的元素加 will-change: transform，提前升层
- 吸顶逻辑直接用 position: sticky，比 JS 切换 fixed 更稳，不引发高度跳变
验证是否真正生效
打开 Chrome DevTools → Rendering 面板：
- 勾选 “Layout Shift Regions”：红色闪烁区域大幅减少，说明布局移位收敛
- 勾选 “FPS Meter”：曲线稳定在 55–60 之间，而非频繁跌至 20–30
- 若仍有大量黄色 Layout 条，说明还有隐藏的读写混用，重点检查第三方库、事件回调、或 useLayoutEffect 中的 DOM 访问
