requestAnimationFrame 适用于需与屏幕刷新率同步的连续视觉更新，如滚动视差、Canvas 绘图等；一次性动画应优先用 CSS transition。其核心是递归调用加时间戳控制，使用浏览器提供的高精度 timestamp，避免 Date.now()。
requestAnimationFrame 什么时候该用，什么时候不该用
它不是万能的“高性能动画开关”，只适合需要和屏幕刷新率同步的连续视觉更新。比如滚动视差、Canvas 绘图、CSS transform 动画驱动、物理模拟等。如果只是做一次性的淡入（opacity 从 0 到 1）、或者状态切换（如菜单展开/收起），直接用 CSS 过渡（transition）更轻量，浏览器会自动优化到合成层，requestAnimationFrame 反而增加 JS 执行开销。
最简可用的 requestAnimationFrame 动画循环结构
核心是「递归调用 + 时间戳控制」，避免用 setInterval 或无条件 setTimeout。浏览器传入的时间戳（DOMHighResTimeStamp）是单调递增的毫秒数，比 Date.now() 更精准，也避免了系统时间被手动调整导致的跳帧。
let startTime = null;
const duration = 3000; // 动画总时长 3s
<p>function animate(timestamp) {
if (!startTime) startTime = timestamp;
const elapsed = timestamp - startTime;
const progress = Math.min(elapsed / duration, 1);</p><p>// 更新样式，例如平移
element.style.transform = <code>translateX(${progress * 200}px)</code>;</p><p>if (progress < 1) {
requestAnimationFrame(animate);
}
}</p><p>requestAnimationFrame(animate);-
timestamp是浏览器保证每帧唯一、高精度的时间值，别自己用Date.now()替代 - 必须在每次回调里检查是否完成（
progress ），否则会无限递归调用 - 不要在
animate里做 DOM 查询（如document.querySelector），应提前缓存element
和 CSS transition / @keyframes 冲突时的表现
如果元素同时被 requestAnimationFrame 修改 transform，又设置了 transition: transform 0.3s，浏览器会把 JS 修改视为“强制重排触发源”，可能打断过渡、导致卡顿或跳变。CSS 动画和 JS 驱动动画不能混用同一属性。
立即学习“前端免费学习笔记（深入）”；
- 已用
requestAnimationFrame控制transform→ 移除所有相关transition声明 - 想保留 CSS 过渡效果 → 改用
element.classList.add('animated')触发 class 切换，完全交由 CSS 管理 - 调试时可打开 Chrome DevTools 的 “Rendering” 面板，勾选 “FPS Meter” 和 “Paint Flashing”，观察是否意外触发 layout/paint
cancelAnimationFrame 的必要性与常见遗漏点
页面卸载、组件销毁、或用户切到其他 tab 时，若没取消正在运行的 requestAnimationFrame，回调仍可能在后台排队执行（尤其在某些旧版 Safari 中），造成内存泄漏或错误访问已销毁的 DOM 节点。
- 保存
requestAnimationFrame返回的 ID：const frameId = requestAnimationFrame(animate) - 在合适时机调用
cancelAnimationFrame(frameId)，比如beforeunload、React 的useEffect cleanup、Vue 的beforeUnmount - 注意：
cancelAnimationFrame不会抛错，传入无效 ID 也无反应，所以不必 try/catch，但要确保变量作用域能访问到 ID
真正难的不是写对那几行 requestAnimationFrame 调用，而是判断它是否真的比 CSS 更合适，以及在组件生命周期里干净地启停。很多“掉帧”问题，根源不在帧率本身，而在反复读写布局属性、或在动画帧里做了重排操作。
