应优先使用transform和opacity等不触发重排重绘的属性实现过渡，避免width、height、top、left等高开销属性；通过DevTools Performance面板定位Layout/Paint瓶颈，并显式声明transition-property、合理使用will-change与translateZ(0)优化合成层。
为什么同时过渡多个 CSS 属性会拖慢动画
浏览器在执行 transition 时，若涉及触发重排（reflow）或频繁重绘（repaint）的属性，就会显著增加主线程压力。比如 width、height、left、top、margin 这类会改变布局的属性，每次变化都可能迫使浏览器重新计算整个元素及其后代的位置和尺寸。
更关键的是，一旦过渡中包含未被硬件加速的属性，GPU 就无法接管，所有工作都压在 CPU 上——尤其在低端设备或复杂 DOM 场景下，掉帧、卡顿立刻出现。
常见错误现象包括：
- 滚动时过渡动画突然卡住
- 多个卡片同时 hover 过渡，页面明显变“沉”
- DevTools 的 Performance 面板里看到大量
Layout和Paint块密集堆积
哪些属性过渡最安全、最高效
能走合成层（compositing layer）、不触发 Layout 或 Paint 的属性，才是过渡性能的“优等生”。目前最稳妥的是这三类：
立即学习“前端免费学习笔记（深入）”；
只影响合成层的属性（推荐优先用）：
-
transform（如translateX()、scale()、rotate()） opacity
注意避开这些高开销属性（除非必要且已测过）：
-
width/height→ 改用transform: scale() -
top/left→ 改用transform: translate() -
background-color→ 虽不触发布局，但会触发 Paint；可考虑用opacity+ 半透明遮罩模拟
示例对比：
/* 慢：触发 Layout + Paint */
.box { transition: width 0.3s, background-color 0.3s; }
<p>/<em> 快：只走合成 </em>/
.box { transition: transform 0.3s, opacity 0.3s; }
.box:hover { transform: scale(1.1); opacity: 0.9; }
如何定位并精简当前过渡的属性
别靠猜。打开 Chrome DevTools → Performance 标签 → 点击录制，然后手动触发过渡动作（如 hover、点击），停止后查看火焰图。
重点关注以下信号：
- 横向长条中频繁出现
Layout或Update Layer Tree→ 说明有布局变动 -
Paint块面积大且密集 → 可能是颜色、阴影、边框等重绘属性过多 - 主线程帧时间 > 16ms（即低于 60fps）→ 已超载
实操建议：
- 用
CSS.transition-property显式声明只过渡必要属性，而不是写transition: all 0.3s - 对批量元素（如列表项）做过渡时，加
will-change: transform提前提示合成，但仅限真正需要的元素，避免滥用 - 用
getComputedStyle(el).transitionProperty在控制台检查实际生效的过渡属性，确认没被层叠覆盖
移动端和低配设备上的特殊处理
iOS Safari 和部分 Android WebView 对 transform 的优化不如桌面 Chrome，尤其是嵌套层级深、有 overflow: hidden 或 backface-visibility 未设的场景，容易意外退化到软件渲染。
稳妥做法：
- 给过渡容器加
transform: translateZ(0)或will-change: transform强制提升为合成层（但别全页加） - 避免在
:active或快速连点状态下启动过渡，可用pointer-events: none临时禁用，或节流过渡触发 - 用
@media (prefers-reduced-motion: reduce)关闭非关键过渡，既省性能又符合可访问性
过渡性能问题往往不是“能不能动”，而是“动哪几个、怎么动、动给谁看”。最常被忽略的一点是：哪怕只写了一个 transition: all，只要后续 CSS 中某个规则改了 margin，它就悄无声息地参与了过渡——得查 computed styles 才能看见。
