rAF协调DOM修改的核心是收拢读写操作以避免强制同步回流和重复重绘。✅读取布局操作集中于rAF回调开头，写入操作统一延后；❌禁止单次JS中反复读写触发多次layout。
用 requestAnimationFrame（简称 rAF）协调 DOM 修改，核心是把所有影响布局和样式的操作“收拢”到浏览器下一次重绘前统一执行，避免强制同步回流（layout thrashing）和重复重绘，从而消除闪烁与掉帧。
把读写操作分离，避免强制同步回流
浏览器在遇到“先读后写”的 DOM 操作时（比如先读 offsetTop，再改 style.left），会立即触发同步布局计算——如果这类操作在单次 JS 执行中反复出现，就会严重拖慢帧率，造成卡顿或闪烁。
- ✅ 正确做法：所有读取布局的操作（
offsetHeight、getBoundingClientRect()、computedStyle等）集中放在 rAF 回调开头一次性完成 - ✅ 所有写入样式或结构的操作（
element.style.transform、classList.add、innerHTML等）统一放在读取之后，或延迟到下一个 rAF 中批量处理 - ❌ 避免：在一个循环里反复读一个元素高度又立刻改它的 margin，这会触发多次 layout
用 rAF 批量更新，跳过中间无效帧
当多个状态变更（如滚动监听、鼠标移动）高频触发时，直接响应会导致大量冗余 DOM 操作。rAF 天然具有“节流+对齐刷新率”的特性，适合做合并调度。
- 用
let pending = false+ 闭包标记控制：只在空闲时注册 rAF，后续变更暂存，等 rAF 触发时一并应用 - 例如实现平滑滚动跟随效果：收集所有需要位移的元素和目标值，rAF 回调中统一用
transform更新，不触发布局 - 避免在
scroll或mousemove中直接修改top/left—— 改用transform: translate()并配合 rAF 调度
动画中优先使用 transform 和 opacity
rAF 能协调时机，但能否不触发重排（reflow）和重绘（repaint）取决于你改的是什么属性。
-
transform和opacity属于合成属性，浏览器可交由独立图层（compositor thread）处理，不打断主线程，也不触发 layout/paint - 避免在 rAF 中设置
width、height、top、left、display等会触发重排的属性 - 若必须动态调整尺寸，考虑用
transform: scale()替代width/height；用visibility: hidden或opacity: 0替代display: none
结合 IntersectionObserver 和 ResizeObserver 减少 rAF 负担
rAF 是协调工具，不是万能补丁。高频轮询或监听本身就会增加压力，应优先用更高效的原生观察机制分流。
- 检测元素是否进入视口？用
IntersectionObserver，它异步回调且不阻塞渲染，无需 rAF 包裹 - 监听尺寸变化？用
ResizeObserver，比在 rAF 里反复查offsetWidth更精准、更低开销 - rAF 应聚焦在“需要精确帧节奏”的环节，比如自定义缓动动画、画布渲染、多元素协同运动等
