核心是让动画脱离主线程交由GPU合成器处理，只操作transform和opacity触发硬件加速，配合will-change谨慎声明、控制图层数量，并用requestAnimationFrame闭环控制。
核心是让动画脱离主线程，交由 GPU 合成器线程处理——不靠“多算”，而靠“少算+分线程”。合成层提升不是开关，而是浏览器根据属性、样式和上下文自动创建图层的过程，JS 的作用是引导它正确发生。
只动 transform 和 opacity
这是触发硬件加速最稳定、兼容性最好的方式。浏览器看到这两个属性变化，会自动将元素提升为独立合成层（compositing layer），后续位移、缩放、透明度变化全部由 GPU 处理，不触发布局（reflow）和重绘（repaint）。
- ✅ 推荐写法：
element.style.transform = 'translateX(120px) scale(1.2)'或element.style.opacity = 0.7 - ❌ 避免写法：
element.style.left = '120px'、element.style.width = '200px'、element.style.backgroundColor = '#ff0'——这些会频繁触发重排或重绘，尤其在大量元素同时动画时，帧率断崖下跌
用 will-change 提前声明（谨慎使用）
它不是性能优化的万能钥匙，而是对浏览器的“善意提示”：这个元素接下来很可能要动 transform/opacity。浏览器收到后，可能提前为其分配独立图层、预分配纹理内存。
- 仅在动画开始前 1–2 帧设置：
element.style.willChange = 'transform' - 动画结束后立即清除：
element.style.willChange = 'auto'（否则长期占用显存，反而拖慢整体渲染） - 不要全局加：
* { will-change: transform }是反模式，会导致大量冗余图层，增加内存压力和合成开销
避免隐式图层爆炸
多个元素各自提升为合成层本是好事，但若无节制，会引发“图层爆炸”——GPU 要管理上百个图层，合成成本反超收益。
- 控制提升范围：优先对动画主体（如轮播项、卡片列表项）单独提升，而非整个容器或父级
- 合并同类动画：如果一组元素做相同位移，考虑用一个
或 CSS@keyframes批量驱动，减少图层数量 - 检查实际图层：Chrome DevTools → Rendering → ✅ “Layer Borders” 可直观查看哪些元素被提升；配合 “FPS Meter” 观察帧率是否随图层数增长而下降
用 requestAnimationFrame + 合成属性闭环控制
JS 不直接操作低效属性，而是专注计算目标值，并通过高效属性输出。整个动画循环必须轻量、可中断、与刷新节奏对齐。
- 每一帧只做三件事：读取当前时间 → 计算新 transform/opacity 值 → 单次赋值（不读 offsetTop 等布局属性）
- 动画启动前调用
cancelAnimationFrame(this.rafId)清理旧任务，防止叠加执行 - 用户滚动或点击时，应立刻中断当前动画并平滑过渡到新状态（例如基于
getComputedStyle(el).transform获取当前矩阵，再插值到新目标）
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
