结论：transition本身不加速，真正起作用的是过渡属性是否触发gpu合成层；仅改transition写法无效，须选用transform/opacity等合成属性，避开layout/paint开销。
直接说结论：transition 本身不加速，真正起作用的是你过渡的属性是否触发合成层（GPU图层）。只改 transition 的写法没用，关键得选对属性、配对行为、避开干扰项。
为什么 transition: left 0.3s 就是卡，而 transition: transform 0.3s 就稳
浏览器对 left、top、width 这类属性的修改，每帧都要重新计算布局（layout）+ 重绘（paint），CPU 满载也难保 60fps；transform 和 opacity 属于「合成属性」，浏览器会把它们单独拎进 GPU 合成层，只做纹理移动或混合，不碰 layout 和 paint。
- 错误写法：
transition: left 0.3s, background-color 0.3s—— 只要其中任一属性非合成，整条过渡就降级到 CPU 渲染 - 正确写法：
transition: transform 0.3s, opacity 0.3s—— 且确保 JS 或 class 切换时，只改这两个属性 - 别信
transition: all 0.3s：它像定时炸弹，某次意外改了margin或color，动画就悄悄变卡
怎么确认 GPU 加速真的生效了
写了 transform: translateZ(0) 不等于就加速了。关键得看浏览器是否真建了独立图层。
- 打开 Chrome DevTools → Rendering 面板 → 勾选 “Layer Borders”：有绿色边框的元素才是被提升的合成层
- 如果没绿框，检查父容器是否设了
overflow: hidden或filter: blur(1px)—— 这些会抑制子元素提层 - 避免在动画元素上同时用动态变化的
box-shadow或filter，它们可能让图层合并失败，退回到 CPU 渲染
will-change 是提示，不是开关，用错反而更卡
will-change: transform 只是告诉浏览器“这个元素接下来可能动”，不是强制指令。静态全局加，等于提前给所有元素塞进 GPU 内存。
- 推荐做法：JS 中动画开始前 1–2 帧设置
el.style.willChange = 'transform' - 监听
transitionend后立刻清除：el.style.willChange = 'auto' - iOS Safari 对极短动画（≤16ms）可能不触发
transitionend，加兜底：setTimeout(() => el.style.willChange = 'auto', duration + 100) - 绝对不要写：
* { will-change: transform; }或.list-item { will-change: transform; }—— 安卓低端机容易 OOM
transform 动画中常见的性能陷阱
即使用了 transform，卡顿仍可能发生——问题往往出在「隐式合成」或「非合成属性干扰」上。
- 比如给一个
position: absolute元素加transform动画，但它的父容器有overflow: hidden或filter: blur(1px)，就会导致该元素无法独立图层化，被迫回退到 CPU 渲染 - 检查 DevTools → Rendering → “Paint flashing” 和 “Layer borders”，看动画区域是否被正确分图层
-
transform: translate3d(0, 0, 0)在部分 Android WebView 中比translateZ(0)更可靠，但注意它仍是 2D 动画，z 轴无实际位移 - 慎用
transform: translateZ(0)在表单内元素上，iOS Safari 旧版本可能引发输入框失焦
最常被忽略的点：动画元素的父容器样式，比它自己更影响 GPU 提层。哪怕你写对了 transform，只要父级加了 filter 或 overflow: hidden，整个加速就失效了。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
