仅transform（translateX/Y/Z、translate3d、scale、rotate）和opacity可触发GPU合成层，其余属性导致整段动画降级CPU渲染；will-change需动态设置并及时清除；须用Chrome渲染面板验证绿色图层边框确认生效。
只对满足条件的 animation 元素临时启用硬件加速，且动画属性严格限定在 transform 和 opacity 范围内——否则浏览器会直接降级回 CPU 渲染，卡顿反而更明显。
哪些 animation 属性能真正走 GPU 合成路径
浏览器仅对以下 CSS 属性的动画触发独立复合层（Compositing Layer），其余都会强制进入主线程 Layout → Paint → Composite 流水线：
-
transform：仅限translateX/Y/Z、translate3d()、scale、rotate；matrix()或混用skew可能被忽略或降级 -
opacity：值在 0–1 之间，且不能和filter、box-shadow同时出现在同一动画中 - 带 3D 上下文的声明：如
transform: translateZ(0)或perspective: 1000px，本质是“提示建层”，但本身不参与动画
以下写法会整段失效：@keyframes slide { to { transform: translateX(100px); box-shadow: 0 2px 4px rgba(0,0,0,.2); } } ——只要动画帧里出现一个非 GPU 友好属性，整条动画就退回到 CPU 渲染。
will-change 必须动态控制，静态写死等于埋雷
will-change: transform 不是开关，而是向浏览器申请提前分配图层资源。静态写在 CSS 里（如 .loader { will-change: transform; }）会导致所有匹配元素长期驻留合成层，内存占用飙升，低端 Android WebView 容易 OOM。
立即学习“前端免费学习笔记（深入）”；
- 正确做法：JS 在动画开始前 1 帧设置，结束立即回收
el.style.willChange = 'transform';el.addEventListener('animationend', () => el.style.willChange = 'auto'); - 如果用
@keyframes+animation，监听的是animationend，不是transitionend - 对纯 CSS 触发的循环动画（如旋转加载图标），可用
setTimeout在动画启动后约 16ms 设为auto，避免漏掉事件
确认硬件加速是否真生效，别信代码写了就完事
写了 translate3d(0,0,0) 或 will-change ≠ GPU 在干活。必须验证图层是否真实创建：
- Chrome DevTools → More Tools → Rendering → 勾选 Layer Borders：绿色边框 = 成功升层；无绿框 = 被父容器压制（如父级有
overflow: hidden或opacity: .99）、动画属性不纯、或浏览器版本太老（Android 4.4 以下不支持） - iOS Safari 更推荐用
transform: translateZ(0)，比translate3d(0,0,0)语义更轻量，兼容性也更好 - 动画持续时间
最常被忽略的一点：哪怕 CSS 全写对了，只要动画过程中 JS 读了 offsetTop、getBoundingClientRect() 或 scrollHeight，就会触发 Forced Synchronous Layout，整条渲染流水线卡死——这时候硬件加速毫无意义。
