动画卡顿应优先检查 requestAnimationFrame 是否滥用；需节流调用、避免重排属性、仅用 transform/opacity、大量元素动画改用 canvas/WebGL。
动画卡顿或掉帧时，优先检查 requestAnimationFrame 是否被滥用
很多页面把多个 setTimeout 或 setInterval 直接塞进循环里驱动动画，结果帧率崩到 20fps 以下。真正该用的是 requestAnimationFrame —— 它由浏览器统一调度，自动对齐屏幕刷新节奏（通常是 60fps），还能在标签页不可见时暂停执行。
但滥用它一样会出问题：比如在滚动监听里反复调用 requestAnimationFrame 而不加节流，每像素滚动都触发一帧，实际渲染跟不上，反而堆积回调、内存升高。
实操建议：
- 用一个全局
rafId变量控制单次激活，每次新动画请求前先cancelAnimationFrame(rafId) - 动画逻辑必须写在
requestAnimationFrame回调内，不要在里面再嵌套setTimeout - 避免在
raf回调中频繁读取offsetTop、getBoundingClientRect()等触发重排的属性
CSS 动画和 JS 动画混用容易引发强制同步布局
比如一边用 transform 做平滑位移，另一边又用 JS 修改 element.style.left 或监听 offsetLeft，浏览器被迫在每一帧里同步计算样式+布局，直接拖垮性能。
立即学习“前端免费学习笔记（深入）”；
典型错误现象：动画开始几秒还流畅，随后明显卡顿，DevTools 的 Rendering 面板里频繁出现 Layout 标记。
实操建议：
- JS 只控制
transform和opacity这类可 GPU 加速的属性；其他样式交给 CSS 类切换 - 需要读取位置时，改用
getComputedStyle(element).transform解析矩阵，而非依赖布局属性 - 给动画元素加上
will-change: transform（仅对长期动画元素，别全页加）
大量 DOM 元素同时动画？用 canvas 或 WebGL 替代逐个操作
当页面有 50+ 个粒子、进度条、浮动图标同时动起来，每个都绑 raf + 操作 style，主线程瞬间过载。这不是节流能解决的，是渲染范式错了。
使用场景：数据可视化动效、游戏化交互、背景粒子系统。
实操建议：
- 把动画对象抽象成数据数组（如
particles = [{x:10, y:20, size:2}, ...]），只在raf中更新数值，绘制统一交给canvas.getContext('2d')批量画 - 复杂图形考虑
OffscreenCanvas（Chrome/Firefox 支持）做离屏渲染，避免阻塞主线程 - 别为了“用 WebGL”而用——简单动画用
canvas足够，WebGL适合需要光照、纹理、大量顶点的场景
const canvas = document.getElementById('anim-canvas');
const ctx = canvas.getContext('2d');
let particles = Array.from({length: 100}, () => ({
x: Math.random() * canvas.width,
y: Math.random() * canvas.height,
vx: (Math.random() - 0.5) * 2,
vy: (Math.random() - 0.5) * 2
}));
<p>function animate() {
ctx.clearRect(0, 0, canvas.width, canvas.height);
particles.forEach(p => {
p.x += p.vx;
p.y += p.vy;
if (p.x < 0 || p.x > canvas.width) p.vx <em>= -1;
if (p.y < 0 || p.y > canvas.height) p.vy </em>= -1;
ctx.beginPath();
ctx.arc(p.x, p.y, 1.5, 0, Math.PI * 2);
ctx.fill();
});
requestAnimationFrame(animate);
}
animate();关键点不在“怎么让动画更炫”，而在“哪些动画根本不该用 DOM 做”。浏览器对 100 个 div 的 transform 尚可应付，但对 100 个 div 的 top/left + border-radius + box-shadow 同时变化，基本等于主动申请卡顿。
