强制同步布局（fsl）是js修改dom后立即读取offsetheight等布局属性，迫使浏览器中断执行、同步重排的静默性能杀手；必须严格先批量读、再批量写，中间零穿插。
读写分离不是加个注释或拆两行代码就能生效的，它要求所有布局读取操作必须在任意样式写入之前全部完成——只要中间穿插一次 el.style.left 或 el.classList.add，浏览器就会立刻 flush 当前 layout，抖动就回来了。
什么是强制同步布局（Forced Synchronous Layout）
这不是报错，而是一种静默性能杀手：你调用 offsetHeight、getBoundingClientRect()、clientTop 等任何需要几何信息的 API 时，如果 DOM 刚被 JS 修改过（比如刚设了 el.style.width），浏览器不得不立刻中断当前 JS 执行、重跑 layout、再把结果返回给你。滚动中每帧触发 3–5 次这种读写交错，帧率直接掉到 20FPS 以下。
常见错误现象：
- 滚动监听里一边
el.scrollTop一边改header.style.transform - 动画循环中每帧都
el.offsetWidth+el.style.left = x + 'px' - 用
for遍历列表，每次循环都读尺寸、再设样式
怎么真正实现读写分离
核心就一条：所有读操作聚合成一批，所有写操作聚合成另一批，且读在写之前、中间不穿插任何 DOM 写行为。
实操建议：
- 批量读取优先用
getBoundingClientRect()，它一次性返回top/left/width/height等全部字段，比反复调offsetTop+offsetWidth快且安全 - 读完立刻缓存结果，后续逻辑全部用缓存值，绝不再碰 DOM 读取 API
- 写操作尽量用
transform和opacity，它们不触发 layout，即使写在读之后也不踩坑 - 实在要改 layout 属性（如
height、margin），确保所有读操作已彻底结束，并且这批写操作之间不夹杂任何读动作
为什么 requestAnimationFrame 不是万能解药
requestAnimationFrame 只保证执行时机在下一帧渲染前，但它不解决读写交错问题。如果你在 requestAnimationFrame 回调里先读 el.scrollHeight、再写 el.style.height、又读 el.offsetHeight，照样触发两次强制 layout。
正确用法：
- 仅用它包裹「整块读写分离后的逻辑」，例如：
requestAnimationFrame(() => { const rect = el.getBoundingClientRect(); el.style.transform = `translateY(${rect.top}px)`; }) - 不要把它当“防抖”用——它不会合并多次调用，也不会跳过中间帧
- 高频场景（如 scroll）建议配合节流，避免每帧都进
requestAnimationFrame
容易被忽略的 DOM 更新陷阱
很多开发者以为“只改 class 就安全”，但 el.classList.add('active') 如果对应 CSS 规则里含 height: auto 或 display: flex，依然可能触发 layout 计算。更隐蔽的是间接影响：改一个元素的 class，可能让父容器因内容变化而重排。
规避要点：
- 检查目标 class 对应的 CSS 是否修改了 layout 相关属性（
width/height/padding/margin/display/position等） - 用 Chrome DevTools 的 Rendering 面板开启「Layout Shift Regions」，滚动时看是否意外高亮
- 真要动态控制尺寸，优先走 CSS 自适应（如
max-height+transition），而非 JS 算完再塞style
最常被绕开的一点：读写分离不是只做一次的事。组件更新、状态重计算、第三方库回调都可能偷偷插入新的读写混杂逻辑——得当成持续审查项，而不是写完就忘的“优化开关”。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
