避免强制同步布局的关键是读写分离：先集中读取offsetWidth等高危属性，再统一修改样式；优先用transform/opacity，高频场景用requestAnimationFrame或ResizeObserver优化。
频繁读写 DOM 样式时避免强制同步布局，核心是**不让浏览器在单次 JS 执行中反复“读→写→读→写”**。只要一次读操作紧跟着一次写操作（尤其是涉及几何信息的读），浏览器就必须立刻执行 layout 来返回准确值，造成性能断崖。
什么是强制同步布局
当 JS 读取 offsetWidth、clientHeight、getBoundingClientRect() 等依赖当前布局状态的属性后，又立即修改影响布局的样式（如 width、top、display），浏览器无法等待批量 flush，只能立刻同步计算 layout —— 这就是强制同步布局。它打断渲染流水线，把本可合并的多次操作拆成多次重排，帧率直线下跌。
高危读操作清单（必须集中前置）
以下任一访问都会触发强制 layout，哪怕只是赋值给变量：
- offsetTop / offsetLeft / offsetWidth / offsetHeight
- clientTop / clientLeft / clientWidth / clientHeight
- scrollWidth / scrollHeight / scrollLeft / scrollTop
- getBoundingClientRect()
- getComputedStyle(element).xxx（任何返回像素值的属性）
正确做法：读写分离 + 批量处理
把所有需要的几何信息一次性读完，再统一写入样式，中间不穿插任何 DOM 修改或其它 layout 触发点：
立即学习“Java免费学习笔记（深入）”；
- 用 getBoundingClientRect() 替代多次 offset/ client 访问，一次调用拿到 left、top、width、height 全部数据
- 循环中先收集全部 offsetTop、clientHeight 等值到数组，再统一设置 transform 或 class
- 写入优先用 transform 和 opacity，它们只触发改绘（paint）或合成（composite），不触发 layout
- 批量更新多个元素时，用 DocumentFragment 或 display: none 临时隐藏父容器，改完再显示
滚动等高频场景的加固策略
监听 scroll 或 resize 时极易踩坑，建议：
- 用 requestAnimationFrame 包裹读写逻辑，确保在下一帧开始前完成全部读取
- 读操作放在 rAF 回调开头，写操作放在结尾，中间不做任何 DOM 查询
- 对尺寸变化敏感的逻辑，优先用 ResizeObserver 替代手动监听 clientWidth 变化
- 避免在滚动中反复读取 el.scrollHeight 后立刻改 el.style.height —— 改用 CSS 自适应或 flex 布局减少 JS 干预
