transition: all 容易引发性能问题，因为它会监听所有可动画属性，包括 width、height 等触发 layout 的属性，导致不必要的重排重绘；应显式声明 transform、opacity 等安全属性。
为什么 transition: all 容易引发性能问题
它会让浏览器对元素所有可动画的 CSS 属性都开启过渡监听，包括那些你根本没打算动的属性（比如 color、box-shadow、font-size），只要它们后续被 JS 修改，就会触发重排或重绘。更关键的是，all 会隐式包含 width、height、left、top 等可能触发 layout 的属性，一旦这些值变化，浏览器不得不同步计算布局，卡顿立刻可见。
transition 应该只写具体属性名
明确列出你要过渡的属性，既避免意外触发，也便于后续维护和性能预判。常见安全组合有：
-
transition: opacity 0.3s ease, transform 0.3s ease—— 最推荐，这两个属性走合成层，不触发布局和绘制 -
transition: background-color 0.2s ease—— 只影响绘制（paint），比 layout 轻，但不如transform/opacity高效 - 避免单独写
transition: width 0.3s或transition: margin 0.3s—— 它们会强制浏览器同步计算尺寸和位置，容易掉帧
用 will-change 配合时更要谨慎
如果同时写了 will-change: transform 和 transition: all，浏览器可能提前升层，但后续任意属性变更（比如 JS 改了 padding）仍会破坏图层缓存，导致回流+重绘+图层重建，反而比不用 will-change 更慢。
/* ❌ 危险组合 */
.element {
will-change: transform;
transition: all 0.3s ease;
}
<p>/<em> ✅ 推荐写法 </em>/
.element {
will-change: transform;
transition: transform 0.3s ease;
}调试时怎么快速发现 all 引发的问题
Chrome DevTools 的「Rendering」面板打开「Paint flashing」和「Layout Shift Regions」，再触发交互。如果看到大面积黄色闪烁（paint）或紫色框（layout），且你只改了 transform，那大概率是 transition: all 在监听其他属性变动。也可以在 Elements 面板里搜索 transition，把所有 all 替换成显式属性列表，再对比帧率。
立即学习“前端免费学习笔记（深入）”；
真正要小心的不是写错语法，而是写得太“省事”——all 看似方便，实际把性能决策权交给了浏览器，而浏览器往往选最保守（也最慢）的路径。
