先记住这个答案
all 的含义是「所有可过渡属性都参与」，浏览器仍只会为真正发生变化的属性创建过渡，所以与显式列出相同属性相比，样式计算和合成开销几乎相同。差异主要在三处：一是 all 无法为不同属性设置不同时长和缓动；二是后续新增样式可能被意外触发过渡；三是监听大量布局类属性会放大意外过渡的代价。工程上推荐只列出需要过渡的属性，把 all 留给属性集合稳定的简单微交互。
- all 只让变化的属性产生过渡，开销接近显式列表
- all 不能按属性区分时长与缓动
- 新增样式可能被 all 意外触发过渡
- 性能关键在属性类型而非写法本身
all 与显式列表在样式计算中的真实开销
transition-property 的初始值就是 all，含义是所有可动画属性在值变化时都可触发过渡。浏览器在每个样式重算周期中对比前后计算值，发现某个被监听属性变化且可插值时才创建过渡对象。因此 all 并不会给所有属性每秒插值，只是扩大了「变更检测」的候选集，这部分检测本身是廉价的查表与比较。
真正的帧开销取决于被触发过渡的属性类型：过渡到 transform、opacity 时通常只更新合成层，不进入布局与绘制；过渡到 width、margin 等布局属性时，每帧插值结果会迫使布局重算。显式列表与 all 在这层没有本质区别，区别只在于显式列表像白名单，挡住了未来不该被过渡的属性被自动接管。
侧边栏收展组件中 all 引发的意外过渡
考虑一个假设的后台系统场景：侧边栏原本只过渡 transform 实现滑入滑出，开发者图省事写了 transition: all .3s。假设半年后另一位同事给同一容器补了 width 从 240px 到 64px 的折叠样式，那么宽度变化会被 all 静默接管，每帧插值 width 将触发整页布局重算，低端设备上收展可能出现明显掉帧；这种排查中往往会发现元凶不在新代码而在旧的 all。
修复方式是：将声明改为 transition: transform .3s，宽度折叠改为对容器做 scaleX 或对内容做位移补偿，让动画保持在合成阶段。预期在修复后收展动画可恢复稳定 60fps。这个假设案例说明 all 的性能问题往往不是当下写出慢代码，而是把未来的样式改动变成隐式的动画入口，约束消失后代价由属性类型决定。
.sidebar {
transition: transform 0.3s ease;
transform: translateX(0);
}
.sidebar.collapsed {
transform: translateX(-176px);
}
/* 反例：后续任何属性改动都会被接管 */
.sidebar-bad {
transition: all 0.3s ease;
}适用于现代浏览器的组件样式：第一种只监听 transform，宽度类改动不会触发动画；第二种 all 会把之后新增的 width、padding 等变更全部变成过渡，布局属性被插值时会引起逐帧重排。
什么时候 all 可以接受、什么时候必须改写法
all 可接受的边界是：元素属性集合小且稳定、只包含合成友好的属性、团队不会给该选择器追加布局类样式。例如一个纯展示图标只过渡 transform 和 opacity，写 all 与写两个属性在性能上无法区分，调试工具中也看不到额外合成开销。此时争论两者性能属于过早优化。
必须改写法的边界有三：需要不同属性用不同时长缓动时，all 语义上做不到，只能拆成属性列表配合 transition 简写逐项声明；选择器作用在会被频繁迭代的通用容器上时，all 会把未来改动变成回归风险；元素数量巨大且被过渡的是布局属性时，应先用性能面板确认瓶颈，再考虑改为合成属性方案，代价是视觉实现更绕。
容易答错的地方
- all 会对所有属性逐帧插值所以一定更慢
- 错误。浏览器只给计算值真正变化的属性创建过渡，未变化的属性不参与插值。
all与列出同一组属性的帧开销基本相同，慢的根源是被过渡属性的类型，而非写法。 - 性能差就删掉过渡改成瞬时切换
- 错误。若瓶颈是布局属性被逐帧插值，正确做法是把动画改到
transform或opacity上并保持过渡，删除过渡牺牲了可用性却没解决样式架构问题。
面试官还会怎么问？
all 会影响合成层创建吗？
不会直接创建合成层。层提升由 will-change、3D 变换、进行中的 transform/opacity 动画等因素触发，transition-property 取什么值只决定哪些变更会产生过渡，不改变分层策略。
想给不同属性配不同时长该怎么办？
不能用 all，要在 transition 简写中逐项声明，如 transition: width .2s linear, opacity .4s ease。每组属性对应独立的时长、缓动和延迟，这是显式列表相对 all 的核心能力优势。
如何验证 all 是否真的造成了性能问题？
用开发者工具录制动画期间的主线程活动，若每帧出现大量 Layout 或 Paint，说明被过渡的是布局或绘制属性；再检查该属性是否因 all 被意外接管。若帧内几乎无主线程序工作，则 all 不是问题来源。
参考资料
示例用于理解所注明的运行环境与边界；延伸学习可结合原文中的更多案例。