JavaScript动画核心在于选对时机、控住帧率、避开重排重绘，应优先使用requestAnimationFrame、transform/opacity、Web Animations API，按CSS→Web Animations→canvas→WebGL路径渐进选择技术。
JavaScript 实现动画与高级视觉效果，核心不在“会不会写 setInterval”，而在于**选对时机、控住帧率、避开重排重绘陷阱**。用错方法，动画卡顿、掉帧、耗电快，用户一划就感知到“不原生”。
用 requestAnimationFrame 替代 setTimeout 和 setInterval
浏览器无法保证 setTimeout 的回调准时执行，尤其在页面后台或 CPU 压力大时；setInterval 更是可能累积延迟、跳帧。而 requestAnimationFrame 由浏览器统一调度，自动对齐屏幕刷新率（通常是 60fps），且在标签页不可见时自动暂停。
实操建议：
- 所有逐帧驱动的动画逻辑（如位置插值、透明度渐变）必须包裹在
requestAnimationFrame回调中 - 避免在回调里做 DOM 查询（如
element.getBoundingClientRect()）或样式写入（如el.style.left = '100px'），这些会触发同步布局计算 - 若需控制动画启停，用
let animationId = requestAnimationFrame(...)+cancelAnimationFrame(animationId)
CSS 变换（transform 和 opacity）优先于直接改 top/left/width
修改 top、left、width 等属性会强制触发浏览器重排（reflow）+ 重绘（repaint），开销极大；而 transform: translateX(100px) 和 opacity: 0.5 属于合成层（composited layer），仅触发重绘甚至仅 GPU 合成，性能高出一个数量级。
立即学习“Java免费学习笔记（深入）”；
常见错误现象：
- 用
el.style.left = x + 'px'做横向滚动 → 卡顿明显，尤其低端安卓机 - 动画中频繁读取
offsetTop或写入height→ 触发 layout thrashing
正确做法：统一用 transform: translate3d(x, y, 0)（加 3d 强制 GPU 加速），配合 will-change: transform 提前提示浏览器。
复杂动效用 Web Animations API 而非手写循环
当动画涉及多属性、关键帧、时间曲线、暂停/播放/反向等控制时，手写 requestAnimationFrame 容易失控。原生 Element.animate() 提供声明式接口，由浏览器底层优化，支持事件监听（onfinish）、时间轴控制（currentTime）、与 CSS 动画无缝衔接。
使用场景：
- 按钮点击反馈（scale + opacity 组合）
- 列表项逐个入场（配合
delay和duration计算） - 需要响应用户交互中断动画（如拖拽中暂停）
示例片段：
const anim = el.animate([
{ transform: 'scale(1) opacity(1)' },
{ transform: 'scale(1.2) opacity(0.8)' }
], {
duration: 300,
easing: 'ease-out',
fill: 'forwards'
});
anim.onfinish = () => console.log('done');
高级视觉效果慎用 canvas 或 WebGL，先确认必要性
不是所有“酷炫”都需要 canvas。粒子效果、波纹、滤镜、3D 场景确实绕不开，但代价是失去语义、可访问性降级、内存管理责任全归你。很多所谓“高级效果”，CSS @property + transition + 自定义缓动就能覆盖 70% 场景。
容易踩的坑：
- 在
canvas中每帧清空整个画布（ctx.clearRect()）再重绘 → 低帧率设备直接卡死 - 未限制粒子数量或未做视口裁剪 → 内存泄漏 + 渲染压力飙升
- 用
WebGL实现简单阴影/模糊 → 过度设计，维护成本远高于收益
建议路径：纯 CSS 动画 → Web Animations API → canvas 2D（带脏矩形优化）→ WebGL（Three.js 封装）。
真正难的从来不是“怎么让东西动起来”，而是判断“该不该动”“动多少”“动给谁看”。动画不是装饰，是反馈、是节奏、是克制的表达。
