transition 属性必须写在默认状态的选择器中才生效，例如 .btn { transition: color 0.2s, transform 0.3s; }，而非仅放在 :hover 等伪类里；否则首次交互无过渡，且 all 易引发意外动画。
transition 属性写在哪个选择器里才生效
过渡效果只在被直接修改的 css 属性所在的选择器上触发。如果 transition 写在父元素，但实际变化的是子元素的 opacity，那这个过渡大概率不会动——子元素没继承 transition，它自己又没声明。
常见错误是把所有过渡都堆在 :hover 伪类里，比如：
.btn:hover { color: red; transform: scale(1.1); transition: all 0.3s; }这会导致：首次 hover 时可能没过渡（因为初始状态没声明 transition），且 all 会拉上所有可动画属性，包括你根本没改的 padding 或 font-size，造成意外抖动或卡顿。
- 正确做法：在「默认状态」的选择器中就写好
transition，只列真正要动的属性 - 例如：
.btn { transition: color 0.2s, transform 0.3s ease-out; } - 如果多个状态（hover / active / focus）需要不同缓动或时长，可以分别在对应选择器里重写对应属性的
transition，CSS 会以最近生效的为准
多个 transition 声明同时存在时谁赢
CSS 会按层叠顺序（cascade）取最后一个生效的声明，但不是整个 transition 值被覆盖，而是按「属性粒度」合并。比如：
立即学习“前端免费学习笔记（深入）”；
.box { transition: opacity 0.2s; } .box.active { transition: transform 0.3s ease-in; }此时 .box.active 元素只有 transform 有过渡，opacity 过渡被完全丢弃——因为 transition 是简写属性，新声明会覆盖旧声明，不叠加。
- 想让 opacity 和 transform 都有过渡？必须显式写在一起：
transition: opacity 0.2s, transform 0.3s ease-in; - 不要依赖「多处声明自动合并」，CSS 不支持 transition 的值叠加
- 用 DevTools 的 Styles 面板检查 computed 的
transition-Property，能立刻看清最终生效的是哪几个
transition-delay 导致的视觉错位怎么调
当多个属性设置不同 transition-delay 时，容易出现「先动一个、再动另一个」的割裂感，尤其在悬停进入/离开双向都需要过渡时。
典型问题：按钮 hover 时文字颜色立即变，背景色却等 0.1s 才开始渐变，松开鼠标后背景色又延迟回退，看起来像卡住。
- 统一进出场延迟：如果必须用 delay，确保 hover 和 :not(:hover) 状态下的 delay 对称（比如都设 0.05s），否则进出节奏不对称
- 更稳妥的方式：用
transition-timing-function控制起始/结束节奏，而不是靠 delay 拉时间差。例如用cubic-bezier(0.2, 0.8, 0.4, 1)让背景色「慢入快出」，比硬加 delay 更自然 - 避免对同一元素同时设置
transition-delay和animation-delay，两者叠加逻辑难预测，优先选其一
transform 和 opacity 过渡卡顿的隐藏原因
这两个属性本该硬件加速，但一旦和其它非合成属性（如 width、height、margin）共用同一个 transition，浏览器可能放弃 GPU 加速，全走 CPU 渲染，导致掉帧。
- 分离高成本与低成本属性：给
transform和opacity单独配一组transition（它们可安全合成），其余布局属性另起一行声明 - 检查是否意外触发 layout：比如在 transition 中修改
top+left，不如统一用transform: translate() - 强制合成层有时有用，但别滥用：
will-change: transform, opacity;只在必要时加，且要在过渡前几帧就设好，不能等 hover 才加
过渡冲突的本质，往往是把「状态变化」和「动画控制」混在了一起。拆开写、分层管、每个 transition 只对准一两个明确属性，比堆 all 或反复覆盖更可控。最常被忽略的，其实是默认状态里漏写 transition——等 hover 时再加，已经晚了。