核心是让动画绕过CPU主线程，交由GPU合成处理：优先用transform/opacity替代left/top等触发重排重绘的属性；用requestAnimationFrame控制节奏；合理使用will-change和图层优化；拆分长任务并节流。
核心思路是让动画尽量绕过 CPU 主线程的布局与绘制，转而交由 GPU 合成层处理，同时控制执行节奏和资源争抢。
用 transform 和 opacity 替代位置/尺寸操作
修改 left、top、width、height 等属性会频繁触发布局（重排）和绘制（重绘），全部在 CPU 上完成，开销大。而 transform（如 translateX、scale）和 opacity 属于合成属性，浏览器可直接将其提交给 GPU 合成线程，跳过昂贵的布局与绘制阶段。
- 把
element.style.left = x + 'px'改为element.style.transform = 'translateX(' + x + 'px)' - 动画中避免读写 offsetTop、clientWidth 等触发同步布局的属性
- 对需长期动画的元素，可加
will-change: transform提前提示浏览器优化（但不要滥用）
用 requestAnimationFrame 控制动画节奏
setTimeout 或 setInterval 无法与屏幕刷新率对齐，容易掉帧或强制重绘；requestAnimationFrame（rAF）则保证回调在下一次重绘前执行，天然匹配 60Hz 刷新节奏，且在页面不可见时自动暂停，节省 CPU。
- 用时间差（
currentTime - startTime）驱动动画进度，而非帧数计数 - 避免在 rAF 回调中做大量计算或 DOM 查询，只做样式更新
- 动画结束及时停止：不再调用
requestAnimationFrame
减少图层数量与强制提升的副作用
虽然 transform: translateZ(0) 或 will-change 能启用硬件加速，但每个独立合成图层都会增加内存与 GPU 管理开销。低端设备上过多图层反而导致合成卡顿。
立即学习“Java免费学习笔记（深入）”；
- 仅对真正需要动画的元素启用硬件加速，避免全屏组件都加
will-change - 用 Chrome DevTools 的“Layers”面板检查图层数量，合并相邻静态区域
- 移除未使用的
transform: scale(1.0001)等隐蔽提升写法
限制并发与拆分长任务
动画常伴随数据处理、状态更新等逻辑。若这些 JS 任务耗时超过 50ms，就会阻塞主线程，导致动画丢帧。尤其在低端设备上，并发动画+计算极易让 CPU 占用突破 70%。
- 将复杂计算拆分为小块，用
setTimeout或queueMicrotask分散执行 - 动画期间暂停非关键任务（如非实时的数据聚合、日志上报）
- 使用节流控制动画触发频率，例如滑动中只每 100ms 更新一次位移
