requestAnimationFrame是浏览器原生支持、与屏幕刷新率同步的唯一可靠动画方案，避免掉帧卡顿和高耗电；setTimeout/setInterval因无视刷新周期、后台不暂停、无法适配多设备刷新率而不适用。
用 requestAnimationFrame 实现 javaScript 动画，不是“比 setTimeout 更高级的写法”，而是浏览器原生支持的、与屏幕刷新率同步的唯一可靠方式。不这么写，动画大概率掉帧、卡顿、耗电高。
为什么不能用 setTimeout 或 setInterval 做动画
它们只按固定毫秒数触发，完全不管屏幕是否准备好渲染。比如设 setTimeout(..., 16)，看似对标 60fps，但执行时机可能错开刷新周期，导致一帧被跳过或重复绘制；页面后台运行时它们还在跑，白耗 CPU；更糟的是，不同设备刷新率不同（iphone Pro 是 120Hz，部分笔记本是 48Hz），硬编码毫秒值直接失效。
-
requestAnimationFrame由浏览器调度，保证每次回调都在下一次重绘前执行 - 页面不可见时自动暂停，恢复时继续，省电且合理
- 自动适配当前设备刷新率，无需手动判断
devicePixelRatio或screen.refreshRate
最简可用的 requestAnimationFrame 动画结构
核心就三件事：启动、更新、递归请求。没有“开始/暂停/停止”内置方法，全靠自己控制流程和状态。
let animationId = null; const element = document.getElementById('box'); let x = 0; function animate() { x += 2; element.style.transform = translateX(${x}px);
// 判断是否继续 if (x < 400) { animationId = requestAnimationFrame(animate); } }
// 启动 animationId = requestAnimationFrame(animate);
// 暂停：调用 cancelAnimationFrame(animationId) // 重启：再调一次 requestAnimationFrame(animate)
注意：requestAnimationFrame 的回调函数默认接收一个参数 —— 当前帧的时间戳（domHighResTimeStamp），单位毫秒，精度远高于 date.now()。实际做缓动或时间敏感动画时，应优先用它算差值，而不是依赖 setInterval 那套“每 N 毫秒走一步”的逻辑。
立即学习“Java免费学习笔记（深入）”；
如何做匀速、缓动、中断可拖拽的动画
真实场景中，你几乎不会只写“+2px”。关键在把位移逻辑从“步进”改成“基于时间计算”：
- 记录上一帧时间戳
lastTime，当前帧拿到currentTime，差值delta就是真实经过的毫秒数 - 目标速度若为 “200px/s”，这一帧该走
200 * delta / 1000像素 - 缓动函数（如
easeoutCubic）输入是「已完成比例」，输出是「位置比例」，跟帧率无关，自然平滑 - 拖拽中断时，别清空
lastTime，否则松手后会突变；应记录松手瞬间的位置和时间，后续用新起点继续插值
常见翻车点：requestAnimationFrame 回调里直接改 style.left —— 触发强制同步布局（Layout Thrashing），性能雪崩。务必用 transform + will-change: transform，或改 css 自定义属性配合 transition。
兼容性与降级注意事项
requestAnimationFrame 在 IE10+、edge 12+、chrome 24+、firefox 23+、safari 6.1+ 均原生支持。ios Safari 一直有 bug：在某些 overflow 滚动容器内，requestAnimationFrame 可能被节流甚至暂停，需加 touch-action: manipulation 或监听 scroll 手动唤醒。
真要兼容 IE9 及以下？别费劲了。用 setTimeout 降级只能保功能，保不住体验 —— 此时更该检查是否真有必要支持这些环境，而不是堆补丁。
真正容易被忽略的是：动画元素如果频繁增删 DOM，requestAnimationFrame 回调里还拿着已移除节点的引用，会静默失败。每次执行前务必校验节点是否存在、是否在文档中。