应避免使用 transition: all，因其强制浏览器对所有可动画属性做全量变更检测，引发主线程阻塞、合成层降级及布局抖动，且隐含高开销属性，导致整条过渡链掉帧。
transition: all 会触发浏览器全量属性检查
浏览器看到 transition: all，不是简单“过渡所有能动的属性”，而是强制对每个可动画 CSS 属性做变更检测：哪怕你只改了 opacity，它仍得逐个比对 width、margin、box-shadow、font-size 是否有变。这个过程发生在主线程，频繁触发就会吃掉渲染帧。
尤其在 Safari 和旧版 Firefox 中，这种检查开销更大——Safari 可能因此降级合成层，Firefox 在初始状态含 display: none 时直接跳过整条 transition 规则，DevTools Animations 面板里连时间轴都为空。
all 会隐式包含高开销属性，哪怕你没写它们
transition: all 不受当前样式限制，它会把所有可动画属性都纳入队列，包括那些你根本没在 CSS 里声明、但浏览器默认支持过渡的属性，比如 top、left、height、background-color。一旦其中任一属性后续被 JS 或其他规则意外修改，整条过渡链就立刻卡顿。
- 写
transition: all 0.3s，然后 JS 改了margin-top→ 触发 Layout（重排） - 父容器加了
filter: blur(1px)→ 子元素的transform过渡被迫回退到 CPU 渲染 - 动画中读取
offsetTop后立即写style.transform→ layout thrashing，iOS Safari 9–10 首帧就掉
all 让性能决策权交给浏览器，而它往往选最慢路径
真正走 GPU 合成层、零重排零重绘的，只有 transform 和 opacity。其他所谓“可动画”属性，要么走 paint（如 color），要么走 layout（如 width）。all 混入任意一个非合成属性，整条 transition 就降级——不是部分卡，是全部掉帧。
立即学习“前端免费学习笔记（深入）”；
更隐蔽的问题是维护成本：all 看似省事，半年后你调了个 border-color，发现它也跟着渐变；查了半天才发现是当初全局搜 transition: all 漏改了一处。
怎么快速定位和替换残留的 all
别靠肉眼翻文件。打开 DevTools Elements 面板，用 Ctrl+F（Win）或 Cmd+F（Mac）全局搜索 transition: all 和 transition-property: all，重点盯 :hover、.active、.is-visible 这类动态类。
运行这段脚本快速扫描：
Array.from(document.querySelectorAll('*')).filter(el => getComputedStyle(el).transitionProperty === 'all').forEach(el => console.warn('All transition found:', el))
替换时注意：显式列出属性，例如 transition: transform 0.25s, opacity 0.3s ease-out；多个属性共用同一时长，写成 transition: color, background-color, transform 0.3s ease 即可，不必重复写时长。
最容易被忽略的是：transition 不是“设一次就完事”的配置，它必须持续存在、且起始值明确。写 all 的那一刻，你就把性能控制权交给了浏览器——而它不会替你做取舍。
