CSS transition性能优化核心在于选择被过渡属性：width/height/top/left/margin/padding触发重排，color/background-color/visibility仅触发重绘，transform和opacity仅触发GPU合成层更新，真正轻量。
CSS transition 本身不引起重绘，但你正在过渡的属性会决定是否重绘、重排，甚至是否走 GPU 合成——优化核心不是调 transition，而是选对被过渡的属性。
哪些属性触发重排、重绘或仅合成？
浏览器渲染分三阶段：布局（Layout）→ 绘制（Paint）→ 合成（Composite）。transition 动画卡顿，往往卡在前两步。
-
width、height、top、left、margin、padding：修改即触发重排 → 性能最差 -
color、background-color、visibility：不重排，只重绘 → 开销中等 -
transform（如translateX、scale）、opacity：不重排、不重绘，只走合成层 → 唯一真正“轻量”的选择
例如：.item { transition: left 0.3s; } 看似简单，但每次动画都会强制重排整个父容器及其子元素；换成 transition: transform 0.3s;，GPU 直接处理矩阵变换，帧率基本稳在 60fps。
为什么 transform + transition 能跳过重绘？
transform 不改变文档流，也不影响其他元素布局，浏览器会把它提升为独立合成层（compositing layer），后续动画只更新该图层的变换矩阵，绘制和合成由 GPU 完成。
立即学习“前端免费学习笔记（深入）”；
- 必须用
transform: translateX(0)初始化，不能靠position: relative+left模拟位移 - 避免混用：不要在同一个
transition中同时写transform和width，否则整条规则退化为重排路径 -
will-change: transform只在真正要动画前动态添加（比如mouseenter时），动画结束（animationend或transitionend）后立刻移除，否则图层常驻导致内存泄漏
示例正确写法：
.card {
transition: transform 0.25s cubic-bezier(0.25, 0.46, 0.45, 0.94);
}
.card:hover {
transform: translateY(-4px) scale(1.02);
}
如何验证是否真的避开了重排重绘？
Chrome DevTools 的 Layers 面板和 Rendering 设置是关键工具。
- 打开
More Tools → Rendering，勾选Paint flashing：绿色闪烁表示重绘区域，频繁大面积闪烁说明仍在重绘 - 勾选
Layer borders：看到浅黄色边框即为合成层；过多嵌套的合成层（尤其子元素也带transform）反而增加 GPU 负担 - 在
Layers面板里点开某层，看Reasons for compositing是否含Will-change property或Transform animation，而不是Overlapping content这类意外提升
注意：哪怕用了 transform，如果父容器设置了 overflow: hidden 且子元素超出，仍可能触发额外裁剪绘制；此时需加 transform: translateZ(0) 强制提升，但不如直接重构 DOM 结构来得干净。
容易被忽略的隐性性能陷阱
很多卡顿不是出在 transition 本身，而是周边副作用。
- 滚动中 hover 触发大量
transition：快速进出会导致动画队列堆积，用pointer-events: none在滚动期间临时禁用，或 JS 加节流 - 深层嵌套元素集体
transform：一个列表项内有 5 层带transition的 div，每层都升层 → 合成层爆炸，GPU 内存吃紧 - 未设
contain-intrinsic-size却用了content-visibility: auto：视口外元素高度坍缩，导致滚动条跳动，间接干扰transition的视觉连贯性
真正要优化的从来不是过渡时间或缓动函数，而是确保过渡只发生在 GPU 可接管的属性上，并让浏览器少做一点不该做的计算——这点在长列表、高频交互场景里，差的不是毫秒，而是掉帧与流畅的分界线。
