保障视觉流畅度的关键是让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* 查询。