应优先使用 requestAnimationFrame 实现动画，因其对齐屏幕刷新率、避免掉帧；CSS 动画优于 JS 动画，仅用 transform/opacity 等可合成属性；杜绝强制同步布局，集中读写操作；按需降帧并响应 prefers-reduced-motion。
用 requestAnimationFrame 替代 setTimeout 或 setInterval
浏览器对 requestAnimationFrame 有专门调度优化，它会自动对齐屏幕刷新率（通常是 60fps），而 setTimeout 的执行时机不可控，容易掉帧甚至堆积任务。尤其在页面后台运行或 CPU 负载高时，setTimeout 仍强行触发，造成视觉卡顿或动画突跳。
- 始终把动画逻辑写在
requestAnimationFrame回调里，不要用setInterval(fn, 16)模拟 60fps - 如果需要暂停/恢复，用布尔标志位控制是否继续调用
requestAnimationFrame，而不是clearInterval - 避免在回调中做大量计算或 DOM 查询；把耗时操作（如路径预计算、数据解析）提前做完
CSS 动画优先于 JS 动画
只要动画效果能用 transform 和 opacity 实现，就坚决用 CSS @keyframes 或 element.animate()。这类属性被浏览器标记为“可合成”（composited），能在独立图层由 GPU 加速，不触发重排（reflow）和重绘（repaint）。
- 禁止在动画中修改
width、height、top、left等触发布局的属性 - 给动效元素加
will-change: transform（仅对即将动画的元素，勿滥用）或transform: translateZ(0)强制提升为合成层 - 慎用
filter（如blur()）、box-shadow，它们虽不触发重排，但会显著增加合成器负担
避免强制同步布局（Forced Synchronous Layout）
这是 JS 动画卡顿最隐蔽也最常见的原因：在修改样式后立刻读取布局相关属性（如 offsetTop、getBoundingClientRect()、scrollHeight），迫使浏览器立即执行重排，打断渲染流水线。
- 把所有“读取布局”的操作集中到一帧开头，所有“写入样式”的操作集中到一帧结尾
- 用
getComputedStyle替代offsetTop等只读属性时，注意它也可能触发同步布局——先缓存结果，别在循环里反复调用 - 使用
ResizeObserver替代监听window.resize+ 手动查尺寸；用IntersectionObserver替代滚动中反复调用getBoundingClientRect()
控制动画帧率与资源开销
不是所有动画都必须跑满 60fps。过度追求帧率反而导致功耗升高、设备发热、低端机直接卡死。关键是要让动画「感知流畅」，而非「绝对高帧率」。
立即学习“前端免费学习笔记（深入）”；
- 复杂粒子动画、Canvas 绘图动画，主动降帧到 30fps（即每两帧调用一次
requestAnimationFrame）更稳 - 移动端务必监听
prefers-reduced-motion媒体查询，对开启“减少动态效果”的用户关闭非必要动画：@media (prefers-reduced-motion: reduce) { * { animation-duration: 0.01ms !important; animation-iteration-count: 1 !important; } } - 用
performance.now()记录每帧耗时，持续 > 16ms 的帧要重点排查；Chrome DevTools 的 “Rendering” 面板可开启 FPS meter 和 “Paint flashing” 快速定位问题
实际卡顿往往不是单点问题，而是多个小失误叠加：比如一边用 left 做位移，一边在 requestAnimationFrame 里反复查 offsetHeight，再叠加未节流的 scroll 监听——这种组合在中低端安卓机上基本必卡。盯住合成层、避开同步布局、按需降帧，比堆砌技巧更管用。
