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 控制。
立即学习“Java免费学习笔记（深入）”；
-
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（单位毫秒），但需确保动画已启动（readypromise 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 链或用状态机约束。
