直接结论：用transform: translateZ(0)或translate3d(0,0,0)显式创建合成层，配合仅变更transform和opacity的动画，才能真正卸载到合成线程；will-change只是提示，不强制建层，移动端尤其不稳定。
直接结论：用 transform: translateZ(0) 或 transform: translate3d(0, 0, 0) 显式创建合成层，配合仅变更 transform 和 opacity 属性的动画，才能真正把转场卸载到合成线程——不是开了“GPU渲染”开关就自动变流畅。
为什么 translateZ(0) 比 will-change: transform 更可靠
移动端浏览器（尤其是 iOS Safari）对 will-change 的实现不稳定：它只是提示，不强制建层；若后续没真实触发 transform 变化，层白建了，还占内存。而 translateZ(0) 是强制提升为独立合成层的最兼容写法，Android WebView、UC、QQ 浏览器都认。
实操建议：
- 只在确实卡顿的转场元素上加，别全局写
* { transform: translateZ(0); } - 避免嵌套使用：父容器和子元素同时加
translateZ(0)→ 层爆炸，iPhone SE 上 50+ 层可能吃掉 100MB 显存 - 不要和
filter: blur(0)混用——部分低端 Android 会直接退回到 CPU 渲染，帧率断崖下跌
哪些 CSS 属性动了才真走 GPU 路线
只有变更 transform（translateX/rotate/scale 等）和 opacity 时，浏览器才跳过 layout + paint，只做 composite。其他属性哪怕只改 left 或 top，都会触发布局重排，GPU 加速完全失效。
立即学习“前端免费学习笔记（深入）”；
常见错误现象：
- 用
transition: left 0.3s做侧滑，再加translateZ(0)也救不回来 - 轮播图里给整个
.carousel加加速，但内部图片用width+height缩放 → 子元素被拖进同一复合层，一动全重绘 - 某些 Android WebView 对
opacity: 1不建层，得设成opacity: 0.99才生效
怎么确认 GPU 加速真起了作用
不能靠“看起来顺”，得看 Chrome DevTools 的硬指标：
- 打开 Layers 面板，悬停转场元素，确认有清晰边界且标注
Composited - Performance 面板录制动画，火焰图里只看到
Composite Layers块，没有Layout或Paint - Rendering → Paint flashing 开启后，动画期间屏幕不该大面积绿色闪烁（否则还在重绘）
注意：iOS Safari 不显示 Layers 面板，只能靠 Performance 录制 + 实测帧率判断；Android 设备需开启“开发者选项→启用 GPU 渲染”，但这只是系统级 2D 加速开关，和网页内合成层无关。
真正卡顿的根源从来不是“GPU 没开”，而是动画中途漏掉了 layout 或 paint。建层要精准，别贪多；改属性要克制，只碰那两个能走合成线程的。
