保障视觉流畅度的关键是让rAF严格对齐VSync信号，确保整条渲染流水线（JS、样式、布局、绘制、合成）在单帧周期内完成；rAF是调度器而非加速器，超时即丢帧，需分阶段执行、规避强制同步布局，并监控完整帧生命周期。
要保障视觉流畅度，关键不是让requestAnimationFrame（简称 rAF）“尽量多调用”，而是让它每次执行都落在屏幕刷新节奏的节拍点上——也就是严格对齐 VSync 信号。rAF 本身不控制帧率，它只是浏览器提供的一扇“准时入场”的窗口；真正决定是否卡顿的，是你的 JS 逻辑、样式计算、布局、绘制、合成这整条渲染流水线能否在单个刷新周期内（如 16.6ms 对应 60Hz）全部完成。
理解 rAF 的本质：它是调度器，不是加速器
rAF 并不保证每帧都执行成功，也不自动优化你的代码。它只做一件事：在下一次屏幕刷新前，通知主线程“现在可以安全地更新画面了”。如果前一帧的 JS 执行 + 样式计算 + 布局 + 绘制 + 合成耗时超过 16.6ms，当前 rAF 回调就会被跳过，直接进入下一帧调度——这就造成丢帧和肉眼可感的卡顿。
- rAF 回调触发时机由浏览器统一协调，与显示器刷新强绑定，无法手动提速或插帧
- 连续两次 rAF 调用之间的时间差 ≠ 实际渲染间隔；若某次耗时超限，时间差会变成 33ms、50ms 甚至更长
- 用
console.time测量 rAF 回调内部耗时，只能反映 JS 阶段压力，不能代表整帧渲染是否达标
监控真实帧耗时：不止看 rAF 回调执行时间
仅测量 rAF 回调函数体的执行时间是片面的。必须结合 performance.getEntriesByType('measure') 或 Chrome DevTools 的 Rendering 面板，观察完整帧生命周期：
- 从 rAF 开始到
layout完成的时间（强制同步布局会显著拖慢） - paint 阶段是否触发全量重绘（避免
width/height/top/left等触发 layout 的属性频繁变更） - composite 阶段是否因图层合并失败而回退到 CPU 合成（检查是否合理使用
will-change: transform或transform: translateZ(0)）
推荐在 rAF 回调开头打点、结尾再打点，并配合 performance.now() 记录，但需注意：若该帧最终被丢弃，这个时间戳就失去了参考价值。更可靠的方式是启用 chrome://tracing 录制完整渲染轨迹。
结构化 rAF 使用：分阶段、可中断、带降级
把重任务拆解为微任务块，在多个 rAF 周期中渐进执行，避免单帧阻塞：
- 动画逻辑与数据更新分离：rAF 中只做 transform 更新，数据计算提前在空闲时段（
requestIdleCallback）完成 - 滚动类交互优先保帧率：监听
scroll时用passive: true，并在 rAF 中聚合多次 scroll delta 再统一处理 - 设置帧耗时阈值（如 12ms），一旦检测到当前帧已逼近上限，主动跳过非关键更新（如暂停粒子动画、降低阴影精度）
例如实现一个平滑滚动跟随效果，不要在每次 rAF 中都重新计算所有元素位置，而是缓存上一帧结果，仅基于位移差做增量更新。
规避隐式同步操作：它们是 rAF 流畅度的最大杀手
以下操作会在 rAF 回调中触发强制同步回流（Forced Synchronous Layout），直接打断渲染流水线：
- 读取
offsetTop、clientWidth、getComputedStyle().height等布局信息后，立即修改样式 - 在同一个 rAF 中多次读写 DOM 样式（“读-写-读-写”模式）
- 未预设宽高而动态插入图片或字体，导致后续帧反复 relayout
解决方式很明确：批量读取 → 批量写入；所有布局读取放在 rAF 开头一次性完成；所有样式写入放在末尾集中提交；必要时用 getBoundingClientRect() 替代多次 offset* 查询。
