17370845950

requestAnimationFrame 是实现平滑动画的首选，它原生支持、自动适配刷新率、避免时间漂移；需分离读写操作、避免强制同步布局，优先使用 transform 和 opacity 以启用硬件加速。

用 requestAnimationFrame 写平滑动画最可靠

浏览器原生支持、自动适配刷新率、避免 setTimeout 或 setInterval 的时间漂移问题，是手动实现动画的首选。它不保证每秒正好 60 次调用，但会尽力对齐屏幕刷新节奏。

常见错误：在回调里直接修改 DOM 样式后立刻读取（如 offsetTop），触发强制同步布局（layout thrashing）。应把读和写分开，或用 getComputedStyle 缓存值。

• 必须在回调函数里再次调用 requestAnimationFrame 才能持续执行
• 动画逻辑中避免频繁访问 offsetHeight、clientWidth 等会触发重排的属性
• 用 performance.now() 计算时间差，比 Date.now() 更精确

let startTime = null;
function animate(timestamp) {
  if (!startTime) startTime = timestamp;
  const elapsed = timestamp - startTime;
  const progress = Math.min(elapsed / 1000, 1); // 动画总时长 1s
  element.style.transform = `translateX(${progress * 200}px)`;
  if (progress < 1) requestAnimationFrame(animate);
}
requestAnimationFrame(animate);

CSS transition 和 animation 覆盖大多数简单场景

纯 CSS 方案性能最好（常运行在合成线程），无需 JS 干预，适合状态切换类动效：hover、toggle、show/hide。

容易踩的坑：transition 不会响应 JS 直接赋值的内联样式变化（除非加 !important 或用 style.cssText），推荐通过增删 class 控制。

• transition 适合单次状态变化，需明确指定属性名（如 transition: opacity 0.3s ease），写 all 易引发意外重绘
• @keyframes + animation 适合循环、多段、复杂路径动画，但无法用 JS 精确控制播放进度（animationPlayState 只能暂停/恢复）
• 需要 JS 响应动画结束？监听 transitionend 或 animationend 事件，注意带前缀的旧版浏览器

用 Web Animations API 实现精细控制

这是 JS 原生提供的、介于 CSS 和 requestAnimationFrame 之间的方案，支持暂停、回放、动态调整时间轴，且兼容性已覆盖 Chrome/Firefox/Safari/Edge（iOS Safari 17.4+ 支持完整特性）。

常见误用：直接对 element.animate() 返回的 Animation 对象反复调用 play()，可能报错 InvalidStateError。应先检查 animation.playState 状态。

• 动画参数用对象字面量传入，keyframes 是数组（同 CSS @keyframes），options 包含 duration、easing、fill 等
• 多个动画同时作用于同一属性时，后调用的 animate() 会覆盖前面的，需手动管理 Animation.effect
• 想获取当前播放进度？用 animation.currentTime（单位毫秒），但需确保动画已启动（ready promise resolved 后）

const anim = element.animate(
  [{ opacity: 0 }, { opacity: 1 }],
  { duration: 500, easing: 'ease-out' }
);
anim.onfinish = () => console.log('done');
// 暂停
anim.pause();
// 跳到 75% 进度
anim.currentTime = anim.effect.getTiming().duration * 0.75;

别忽略性能敏感点：哪些属性能硬件加速

不是所有 CSS 属性动画都高效。只有 transform 和 opacity 能走合成层（compositor thread），其余如 width、height、top、left 会频繁触发 layout → paint → composite 流程，卡顿明显。

一个典型反例：用 margin-left 实现横向滚动动画，在长列表中极易掉帧。换成 transform: translateX() 就能显著改善。

• 强制开启 GPU 加速？加 transform: translateZ(0) 或 will-change: transform，但别滥用——浏览器会提前分配纹理内存，过多反而拖慢初始化
• 动画元素层级深、父容器有 overflow: hidden 或 filter，可能破坏合成层提升，用 Chrome DevTools 的 Layers 面板验证
• 移动端要注意：touch-action: none 可防止滚动冲突，但会禁用原生手势；更稳妥的是在动画期间临时设为 pan-x pan-y

用 requestAnimationFrame 写逻辑、用 transform/opacity 做变化、用 class 触发 CSS 动画——这三者组合能覆盖绝大多数需求。真正难的是在复杂交互中保持动画状态与 JS 状态同步，比如拖拽中突然触发折叠，这时候靠 cancel() 和重新 animate() 很容易丢帧，得预留 cancelable 的 Promise 链或用状态机约束。