transition本身不触发GPU加速，必须配合transform、opacity或filter等可硬件加速的CSS属性；left、top等属性会触发重排重绘，无法进入GPU合成层。
transition 本身不触发 GPU 加速，必须配合 transform 或 opacity
浏览器对 transition 的处理默认走 CPU 软件渲染，哪怕你写了 transition: all 0.3s，只要过渡的属性是 left、top、width 这类会触发 layout 或 paint 的属性，就不可能进 GPU 合成层。真正能被硬件加速的只有少数几个 CSS 属性：transform、opacity、filter（部分浏览器支持）。所以想让 transition 流畅，第一步是把动画逻辑迁移到这些属性上。
常见错误：写 transition: left 0.3s 然后指望它变快——它不会。Chrome DevTools 的 “Rendering” 面板打开 “Paint flashing” 就能看到绿色重绘块疯狂闪烁。
- ✅ 正确做法：用
transform: translateX(100px)替代left: 100px - ✅ 正确做法：用
opacity: 0.5替代visibility: hidden或display: none（后者根本不可过渡） - ❌ 错误组合：
transition: background-color 0.3s—— 触发重绘，无硬件加速 - ❌ 错误组合：
transition: margin 0.3s—— 触发重排，CPU 全程扛着
为什么加了 translateZ(0) 还卡？可能是图层没真正提升
加 transform: translateZ(0) 是为了“哄”浏览器给元素单独建一个合成层（compositing layer），但这个操作不是 100% 成功。旧版浏览器（如 IE11、Android 4.4 WebView、Safari 9）对合成层创建规则更苛刻，仅靠 translateZ(0) 可能无效，必须搭配其他触发条件。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 优先用
transform: translate3d(0, 0, 0)，比translateZ(0)在 Safari 9 和部分 Android WebView 中兼容性更稳 - 如果元素有父级设置了
overflow: hidden或will-change: scroll-position，可能抑制子元素的图层提升，需检查层级关系 - 不要在所有元素上无差别加
translate3d，每个合成层都占 GPU 内存；Chrome 的 “Layers” 面板可查看实际创建的图层数量 - 移动端尤其注意：iOS Safari 对
will-change: transform支持不稳定，有时反而导致闪屏或 z-index 错乱，慎用
transition + will-change 怎么配才不翻车
will-change 是提示浏览器“这个元素接下来要动”，但它不是开关，而是优化建议。滥用会导致内存暴涨、字体发虚、z-index 异常，甚至在某些安卓机型上直接白屏。
安全用法：
- 只在真正需要过渡前一刻设置：
element.style.willChange = 'transform'，动画结束立即清空：element.style.willChange = 'auto' - 绝对不要写在 CSS 里全局声明：
.card { will-change: transform; }—— 页面一加载就强制建图层，得不偿失 - 替代方案更稳妥：用
transform: translate3d(0, 0, 0)静态触发图层，再用transition: transform 0.3s控制动画，省心且兼容 - 注意：
will-change: opacity在部分旧版 Firefox 中会禁用 subpixel 字体渲染，文字边缘明显锯齿
旧浏览器（IE11/Safari 9/Android 4.4）卡顿的硬解法
这些环境根本不按规范走合成层逻辑，transition 卡顿大概率不是代码问题，而是浏览器压根没进 GPU 渲染管线。这时候不能靠“优化”，得换思路。
可行路径：
- 降级为 JS 动画 +
requestAnimationFrame，配合transform写法（避免top/left），比原生transition更可控 - 对关键动效元素加
-webkit-transform: translate3d(0,0,0); transform: translate3d(0,0,0);，并确保没有backface-visibility: hidden干扰（Safari 9 下该属性有时阻断加速） - 禁用模糊、阴影等
filter效果——它们在旧 WebView 中常退化为 CPU 渲染，比transition本身还拖慢 - 测试时务必用真机：模拟器里的 Chrome 没有 GPU 限制，但 Android 4.4 系统 WebView 实际跑的是软件 Skia 渲染器，性能差距极大
最麻烦的点往往不在 transition 写法，而在你没意识到：某些 CSS 规则（比如父容器的 perspective 或 transform-style: preserve-3d）会意外合并图层，让本该独立加速的元素被拖进主渲染层——这种问题只能靠 Layers 面板一层层点开看。
