requestAnimationFrame 更适合动画因其与屏幕刷新率同步、自动暂停省电、需配合时间戳防速度不均；CSS transition 适合简单属性变化，而 requestAnimationFrame 适合复杂交互控制。
requestAnimationFrame 为什么比 setTimeout 更适合动画
因为 requestAnimationFrame 与屏幕刷新率同步（通常 60fps），不会出现丢帧或卡顿；而 setTimeout 的执行时机不可控，容易累积延迟，尤其在页面后台运行或 CPU 压力大时帧率骤降。
- 浏览器会在下一帧绘制前自动调用回调，无需手动计算时间间隔
- 页面不可见时，
requestAnimationFrame自动暂停，省电且不浪费资源 - 无法保证每次回调间隔严格为 16.67ms，需用时间戳做差值计算位移，否则会因帧率波动导致速度不均
CSS 过渡（transition）和 requestAnimationFrame 能否混用
能，但必须分清职责：CSS transition 适合简单、状态明确的属性变化（如颜色、尺寸、透明度）；requestAnimationFrame 适合需要逐帧控制逻辑的动画（如物理模拟、滚动跟随、多属性异步变化）。
- 同时设置
transform和transition，再用 JS 改变style.transform，会触发 CSS 过渡——此时requestAnimationFrame反而多余，还可能干扰过渡时序 - 若需在动画中响应用户交互（如拖拽中实时更新位置），必须用
requestAnimationFrame+transform，禁用transition，否则样式冲突会导致跳变 - 用
getComputedStyle(el).transform读取当前矩阵时，不要在requestAnimationFrame回调里频繁读取——会强制同步布局，严重拖慢性能
如何用 requestAnimationFrame 实现缓动平移（easing translate）
核心是用时间戳算出已过去比例 t，再代入缓动函数（如 easeOutQuad），避免固定步长导致的精度丢失和终点偏差。
function animateTranslate(el, fromX, toX, duration = 300) {
const start = performance.now();
const deltaX = toX - fromX;
function step(now) {
const elapsed = now - start;
const t = Math.min(elapsed / duration, 1); // 归一化时间 [0, 1]
const eased = 1 - (1 - t) (1 - t); // easeOutQuad
const x = fromX + deltaX eased;
el.style.transform = `translateX(${x}px)`;
if (t < 1) {
requestAnimationFrame(step);
}}
立即学习“Java免费学习笔记（深入）”；
requestAnimationFrame(step);
}
- 务必用
performance.now()，不用Date.now()，前者精度更高（微秒级），避免长时间运行后误差累积 -
Math.min(elapsed / duration, 1)防止因帧率抖动导致t > 1，造成过冲 - 动画结束时不重置
transform，保留最终状态；如需复用，应显式清理内联样式或使用 CSS 自定义属性驱动
requestAnimationFrame 动画被卡住或掉帧的常见原因
多数不是 API 本身问题，而是 JS 主线程被阻塞或样式操作不当。
- 在
requestAnimationFrame回调里执行大量 DOM 查询（如offsetTop、getBoundingClientRect）、修改 class 或触发 layout —— 立即引发强制同步重排 - 动画元素未启用硬件加速：
transform: translateZ(0)或will-change: transform可让浏览器提前分配合成层，但滥用会导致内存占用升高 - 监听了
scroll或resize并直接在里面调用requestAnimationFrame，却没做节流，导致回调堆积 - 使用
innerHTML或频繁appendChild更新动画容器内容，会打断渲染流水线
复杂交互动画建议把计算逻辑移到 Web Worker，只在主线程做 transform 更新；CSS 层面优先用 transform 和 opacity，这两者可由合成器单独处理，不触发布局和绘制。
