高频DOM操作卡顿本质是“改得太碎”引发强制同步布局，需用rAF配合任务切分、避免读写陷阱、按节点量选择Fragment一次性挂载或分帧处理，并用pending控制节流。
高频 DOM 操作卡顿，本质不是“改得太多”，而是“改得太碎”
直接在 scroll 或 input 事件里反复调用 element.style.left = x + 'px'，哪怕只改 10 个元素，也极易触发强制同步布局（forced layout）。浏览器被迫在每次写入后立刻读取布局信息（比如为了计算下一帧位置），形成“读-写-读”陷阱，主线程被反复打断。真正耗时的不是 DOM 修改本身，而是隐式重排和样式重计算。
requestAnimationFrame 不是“加个函数名就变快”，关键在调度逻辑
requestAnimationFrame 本身不加速 DOM 操作，它只是把执行时机对齐到渲染帧——但必须配合退出控制和任务切分，否则反而更糟：
- 漏掉
cancelAnimationFrame：动画停止后回调仍在注册，内存泄漏 + 持续占用主线程 - 在 rAF 回调里再读
offsetHeight或getComputedStyle：立刻触发 flush，抵消 rAF 的调度优势 - 一次性塞入上千节点构建
DocumentFragment：单帧构建耗时超 8ms，仍会卡顿 - 用
for循环连续调requestAnimationFrame：瞬间注册数百回调，全部挤在下一帧执行，毫无渐进性
批量插入场景：Fragment + rAF 要分“一次批”和“分帧批”
节点数量决定策略：
- 50～200 个节点：用
DocumentFragment全部构建完，再用requestAnimationFrame(() => parent.appendChild(frag))一次性挂载 - 500+ 节点：必须分帧。每帧处理 20～30 个，每次新建
DocumentFragment、append 后立即插入，避免 fragment 累积和单帧过载 - 节点含事件绑定或复杂模板：分帧时把“创建 + 绑定”也拆开，不要在 rAF 回调里做 heavy work
滚动/输入类高频事件，rAF 节流必须带 pending 控制
常见错误是把 requestAnimationFrame 当作防抖函数用，结果仍频繁触发：
立即学习“前端免费学习笔记（深入）”；
- 正确做法：用布尔标记
pendingUpdate，事件触发时只设为true，rAF 回调里执行并重置 - 避免在 rAF 回调中调用
el.getBoundingClientRect()等读布局 API，如需尺寸，提前缓存或用ResizeObserver - 滚动监听慎用
scrollLeft/scrollTop：它们是同步读取，且易引发 layout thrashing
mousemove 中读一次 offsetTop，再设一次 style.transform，就足以让 60fps 掉到 30fps。rAF 不是银弹，它只提供时机，真正的性能收益来自你是否切断了读写依赖链。 
