JavaScript动画核心在于控制requestAnimationFrame节奏、避免强制同步布局、用transform/opacity触发GPU加速；需分离状态计算与样式应用，用performance.now()和帧间插值实现精准动画。
JavaScript 动画效果不是靠“加个动画库”就完事的，核心在于你是否控制了 requestAnimationFrame 的节奏、是否理解 DOM 重排/重绘的代价、以及是否在用错时机更新样式。
为什么直接改 style.left 配合 setTimeout 效果差？
这种写法常见但低效：它绕过了浏览器的渲染调度机制，容易掉帧，且无法与屏幕刷新率同步。更严重的是，每次读取 offsetLeft 或写入 style.left 都可能触发强制同步布局（forced synchronous layout），尤其在循环中会指数级拖慢性能。
实操建议：
- 避免在动画循环中混用读写操作（比如先读
element.offsetTop，再立刻写element.style.transform） - 优先用
transform和opacity触发 GPU 加速，它们不触发重排 - 用
getComputedStyle替代offsetTop等属性读取，减少布局抖动风险
requestAnimationFrame 怎么写才不白用？
它只是告诉浏览器“下一帧请调用我”，但没规定你怎么更新状态或何时提交样式。很多人只把它当 setTimeout 的高刷替代品，却忘了做状态分离和帧间插值。
立即学习“Java免费学习笔记（深入）”；
实操建议：
- 把动画逻辑拆成三部分：计算当前帧状态（如
progress = (Date.now() - startTime) / duration）、应用状态（如el.style.transform = `translateX(${ease(progress) * 100}px)`）、递归调用自身 - 用
performance.now()替代Date.now()，精度更高，避免系统时间跳变干扰 - 动画结束时务必清除引用（如清空
rafId），否则可能内存泄漏
简单示例：
function animate(el, from, to, duration) {
const start = performance.now();
const rafId = requestAnimationFrame(function step(now) {
const elapsed = now - start;
const progress = Math.min(elapsed / duration, 1);
const eased = progress; // 可替换为 easeOutCubic 等
el.style.transform = `translateX(${from + (to - from) * eased}px)`;
if (progress < 1) requestAnimationFrame(step);
});
}CSS 动画和 JS 动画到底该选哪个？
不是“JS 更灵活所以该用 JS”，而是看控制粒度需求。CSS @keyframes 适合声明式、固定路径的过渡；JS 适合需要响应用户交互（如拖拽跟随）、动态计算目标值、或逐帧干预（如物理模拟）的场景。
实操建议：
- 纯入场/退出动效（如 modal 淡入）、状态切换（如按钮 hover 缩放），优先用
transition或@keyframes，浏览器原生优化好 - 需要暂停、倒放、跳转到某进度、或根据鼠标位置实时调整的，必须用 JS 驱动
requestAnimationFrame - 混合使用时，用
el.animate()（Web Animations API）比手写 RAF 更可控，但它在 Safari 中支持有限
动画卡顿的三个隐蔽原因
很多问题不是代码写错，而是被忽略的底层行为：
-
will-change: transform没加——对频繁动画元素提前提示浏览器准备图层，但别滥用，会增加内存开销 - 动画元素父容器用了
overflow: hidden且子元素有transform——某些版本 Chrome 会禁用合成层，导致回退到 CPU 渲染 - 监听了
scroll或resize并直接触发动画——没节流或没用passive: true，造成事件阻塞主线程
真正难的不是让东西动起来，是让动得稳、停得准、切得顺——这些细节藏在每一帧的读写顺序、每一处样式的触发条件、每一次 RAF 的生命周期管理里。
