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 应聚焦在“需要精确帧节奏”的环节，比如自定义缓动动画、画布渲染、多元素协同运动等