应使用 requestAnimationFrame 替代 setTimeout/setInterval 实现动画，因其对齐浏览器刷新帧、避免强制同步布局与掉帧；需批量读写 DOM、优先用 transform/opacity、善用 CSS 动画与 will-change、节流事件并清理动画实例。
用 requestAnimationFrame 替代 setTimeout 或 setInterval
浏览器每秒重绘约 60 次（即 16.6ms 一帧），requestAnimationFrame 会把回调对齐到下一帧开始时刻，避免强制同步布局、掉帧或“抖动”。而 setTimeout(fn, 16) 无法保证准时执行，还可能在非绘制时机触发样式读写，引发 layout thrashing。
- 必须在每次动画帧内完成所有 DOM 读写：先批量读取（如
offsetTop、getBoundingClientRect()），再批量写入（如修改style.transform） - 不要在动画循环里调用
getComputedStyle或访问offsetHeight等触发回流的属性——除非你明确需要且已缓存结果 - 如果只是位移/缩放/旋转，优先用
transform+opacity，它们走合成层，不触发重排重绘
避免强制同步布局（Forced Synchronous Layout）
当 JS 在同一任务中先读取布局信息（比如 el.offsetWidth），又立刻修改样式（比如 el.style.left = '100px'），浏览器不得不立即计算当前样式和布局，打断渲染流水线。这种模式在动画中尤其致命。
- 把所有读操作集中放在帧开头，所有写操作集中放在帧末尾
- 用
el.getBoundingClientRect()代替多次访问offsetTop/offsetLeft——它返回一个快照对象，后续读取不触发新计算 - 若需动态计算位置，先用
getComputedStyle(el).transform解析矩阵，再做运算，而不是靠反复读写style.left
用 CSS 动画 + will-change 提前升层
纯 CSS 动画（@keyframes + animation）由浏览器直接交给合成器处理，比 JS 驱动更省资源。但需配合正确策略，否则无效甚至负优化。
- 只对真正需要动画的元素设
will-change: transform或will-change: opacity，不要全局滥用（会常驻纹理内存） - 避免对
top/left等触发重排的属性做 CSS 动画；改用transform: translateX(100px) - 用
transform: translateZ(0)或transform: scale(1.0001)强制创建独立图层，适用于需要频繁更新但 JS 控制的场景（注意：现代 Chrome 已弱化该技巧效果，仅作兜底）
节流高频事件与清理未完成动画
滚动、鼠标移动等事件可能每秒触发上百次，若每个都调用 requestAnimationFrame，会堆积大量待执行帧，造成延迟或卡顿。
立即学习“Java免费学习笔记（深入）”；
- 用闭包 + 标志位控制：只有上一帧结束才注册下一帧，例如
let isAnimating = false;
function animateScroll() {
if (isAnimating) return;
isAnimating = true;
requestAnimationFrame(() => {
// 执行动画逻辑
isAnimating = false;
});
}
window.addEventListener('scroll', animateScroll);
- 使用
element.animate()时，记得保存返回的Animation实例，在组件卸载或条件变更时调用animation.cancel()或animation.finish()，防止内存泄漏或状态错乱 - 监听
visibilitychange事件，在页面不可见时暂停动画（animation.pause()），恢复时再继续，节省 CPU 和电量
