transition: all 会降低动画性能、引发兼容性问题并增加维护成本，应仅对明确需要过渡的属性单独声明，避免在高频交互和移动端滥用。
用 transition: all 会悄悄拖慢动画帧率
它会让浏览器在每次重绘前，强制检查所有可动画的 CSS 属性是否发生了变化——哪怕你只改了 opacity，浏览器也得比对 transform、color、margin 等二十多个属性。这直接抬高了样式计算（Style Calculation）和布局（Layout）阶段的开销，尤其在中低端设备或复杂 DOM 结构下，容易掉帧。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 只对明确需要过渡的属性写死声明，比如
transition: opacity 0.2s ease, transform 0.2s ease - 避免在高频触发的交互（如
scroll、mousemove）里依赖all，否则卡顿会非常明显 - 用 Chrome DevTools 的「Rendering」面板勾选“Paint flashing”和“FPS meter”，能直观看到
all引起的额外重绘范围
transition: all 在不同浏览器中的兼容性表现不一致
老版本 Safari（≤13.1）对 all 的属性覆盖范围较窄，比如不触发 box-shadow 或 filter 的过渡；而 Firefox 对某些 SVG 属性的 all 响应又过于激进，可能意外触发重排。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 不要假设
all能跨浏览器“一劳永逸”——关键动效务必在目标浏览器中实测 - 若需支持 Safari iOS 12–13，
box-shadow和filter必须单独声明过渡，不能靠all带过去 - 用
@supports (transition: all)做基础检测意义不大，真正要测的是具体属性组合是否生效
写 transition: all 容易掩盖属性变更意图，增加维护成本
当一个元素同时有 opacity、transform、color 变化，但只有 transform 需要 0.3s，其余只需 0.1s，用 all 0.3s 就会导致颜色突变延迟，视觉上“不同步”。更麻烦的是，后续接手的人很难从 CSS 里看出哪些属性本该有独立时序。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 把过渡拆成多条声明，按语义分组：比如
transition-property: transform, opacity和transition-duration: 0.3s, 0.1s - 用 CSS 自定义属性控制时长，方便统一调整：
--dur-move: 0.3s; transition: transform var(--dur-move), opacity 0.1s - 禁止在组件级 CSS 中使用
all，除非是纯装饰性、无交互逻辑的微动效（比如悬停图标边框色）
用 will-change 补 all 不是银弹
有人以为加个 will-change: transform 就能抵消 all 的性能损失，其实不行。因为 will-change 只对提前声明的属性生效，而 all 会激活所有属性，未声明的那些依然走低效路径。更糟的是，滥用 will-change 本身就会引发不必要的图层提升和内存占用。
实操建议：
立即学习“前端免费学习笔记（深入）”；
-
will-change应仅用于已知即将变化、且变化频率低的属性（如模态框入场前的transform），不能当成all的补丁 - 如果真要用
all，优先考虑降级方案：比如用 JavaScript 监听属性变更，动态添加对应transition类名，而不是全局硬写 - 移动端慎用——
all+will-change组合在 iOS WebKit 下容易触发渲染线程阻塞
最麻烦的不是性能数字，而是 all 让人误以为“写少了”，结果调试时才发现某个颜色没过渡、某个阴影闪了一下、某次滚动突然卡住——这些都不是报错，也没有 warning，只能靠眼睛盯、靠帧率工具挖。
