用 transform 和 opacity 能让动画更流畅，因为二者触发合成层、不引发重排重绘，仅走 GPU 合成管线；其他属性如 left、top 或 background-color 则频繁触发重排重绘导致掉帧。
为什么用 transform 和 opacity 能让动画更流畅
因为浏览器对这两个属性做了硬件加速优化：它们触发的是合成（compositing）层，不触发重排（reflow）和重绘（repaint），只走 GPU 的合成管线。换成 left、top 或 background-color 就会频繁触发重排重绘，帧率掉得明显。
关键不是“用了就快”，而是“只改这两个属性时，浏览器才愿意给你开独立图层”。其他属性哪怕只是加个 will-change: transform，也未必真加速——得看实际是否被提升为合成层。
-
transform（包括translate3d(0,0,0)）、opacity是唯二被广泛支持且稳定触发合成的 CSS 属性 - 用
translateX()替代left，用scale()替代width/height，效果一样但性能差一个量级 -
filter、clip-path在部分浏览器中也会触发合成，但兼容性差，别默认依赖
如何确认动画真的走了硬件加速
光写 transform: translateZ(0) 不等于就加速了。得看浏览器是否真给元素建了独立合成层——最直接的办法是打开 Chrome DevTools → Rendering 面板 → 勾选 “Layer Borders”。有绿色边框的元素才是被提升的图层。
- 如果动画元素没绿框，说明还在主渲染线程跑，
transform写得再标准也没用 - 常见干扰项：
overflow: hidden会抑制图层提升；父元素用了transform但子元素没脱离文档流，也可能被合并进父层 - 避免滥用
will-change: transform：它只是提示，不是指令；提前声明太多反而增加内存开销和图层管理负担
transition 和 @keyframes 在加速上的实际差异
两者底层机制一致，只要动画属性是 transform 或 opacity，都能走合成。但写法不当会悄悄退化：
- 用
transition: all 0.3s很危险——只要某次 DOM 更新意外改了非加速属性（比如color），整个过渡就降级到 CPU 渲染 -
@keyframes中混用top和transform，会导致整段动画无法合成；必须全程只用加速属性 - 动画时长太短（如
0.05s）或太长（如3s），都可能影响浏览器调度精度，建议控制在0.2s–0.5s区间
移动端特别容易翻车的几个点
iOS Safari 对合成层更敏感，稍不注意就掉帧。Android 旧版 WebView 则可能压根不支持某些 transform 组合。
- 别用
translate3d(0,0,0)强制提层——iOS 15+ 已不推荐，反而可能引发闪烁；优先用translateY(0)这类语义清晰的写法 -
opacity: 0.99比opacity: 0更稳：某些安卓机型对完全透明的元素会跳过图层创建 - 滚动中触发动画（比如 sticky 导航条淡入）极易卡顿，务必加
transform: translateZ(0)到父容器，确保它本身是合成层
硬件加速不是开关，是浏览器根据属性、上下文、设备能力动态决策的结果。最可靠的写法，永远是只动 transform 和 opacity，并用 Layer Borders 实时验证。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
