能触发过渡的属性需为可动画化属性，如opacity、transform、color等；display、visibility、z-index等不可动画化；transition-property用具体属性名比all更可控，transform性能最佳。
transition-property 哪些值能真正触发过渡
不是所有 CSS 属性都能被 transition 动画化，写错了就完全没效果，连控制台都不报错，纯靠肉眼“感觉不动”。关键看浏览器是否把该属性列为「可动画化属性」（animatable）。
常见能动的： opacity、transform、color、background-color、width、height（但注意盒模型影响）、margin / padding（有性能代价）。
明确不能动的：display、visibility（虽然 visibility 改变是瞬时的，但配合 opacity 可模拟淡入）、position（本身不动画，但 top/left 可以）、z-index、font-family。
-
transition-property: all看似省事，但会强制监听所有变化，包括你根本不想动的属性（比如box-shadow意外变更），可能引发意外重绘 - 用具体属性名比
all更可控，也更容易排查为什么某次状态变更没动画 -
transform是最推荐的动画属性——它走合成层，不触发布局（layout）和绘制（paint），性能远好于改left或width
transition-timing-function 关键字和贝塞尔曲线的实际差异
ease、linear、ease-in-out 这些关键字本质就是预设的 cubic-bezier() 曲线。它们不是“风格选择”，而是直接影响用户感知的节奏感和响应真实感。
立即学习“前端免费学习笔记（深入）”；
比如按钮 hover 用 ease-out 会让进入动作更果断；模态框淡入用 ease-in 能避免“卡顿感”；而 linear 在滚动锚点动画里反而显得机械生硬。
-
cubic-bezier(0.25, 0.46, 0.45, 0.94)这类自定义值，前两数控制起始速率，后两数控制结束速率；超出 [0,1] 范围是允许的（会产生回弹/过冲），但部分旧 Android WebView 不支持 -
steps(4, end)适合做帧动画（如加载指示器），但别误用在需要平滑过渡的场景，否则会“跳变” - 不要在同一个元素上混用
ease-in和ease-out于不同属性——浏览器不会统一协调它们的时序，容易出现“脱节”感
transition-delay 为负值时发生了什么
transition-delay: -0.3s 不是“倒放动画”，而是让过渡**从中间某一帧开始播放**。相当于跳过了前 300ms 的初始状态，直接进入动画进程的 30% 位置。
这在需要“衔接已有状态变化”的场景很实用，比如一个元素已通过 JS 修改了 opacity，你想立刻补上过渡效果，而不是等下一帧再慢慢开始。
- 负延迟只影响动画起点，不影响持续时间或结束状态
- 如果延迟绝对值 ≥ 持续时间（如
delay: -1s+duration: 0.5s），动画会直接跳到最终态，不显示过程 - 慎用于依赖精确时序的交互动画（如拖拽反馈），因为不同设备帧率下负延迟的视觉起始点可能偏移
transition 未生效却无报错？优先检查这三处
CSS 过渡静默失败太常见，往往不是语法错，而是隐性条件不满足。浏览器不会提示“这个 transition 被忽略了”，只会默默跳过。
- 目标属性值是否发生了**可计算的数值变化**？比如从
color: red→color: #f00是同一值，无变化；font-size: 16px→font-size: large因单位不可比，也不触发过渡 - 元素是否处于**可渲染状态**？
display: none的元素上设 transition 完全无效；visibility: hidden则有效，但看不见 - 是否被更高级别的样式覆盖？比如父元素设了
transition: none，或使用了!important强制覆盖了 transition 相关声明
复杂点在于：这些条件常常组合出现。比如一个 transform 动画在 iOS Safari 上突然卡住，大概率是触发了硬件加速限制，或者同时改了 width 和 transform 导致浏览器放弃优化路径。这种时候，单看代码看不出问题，得靠 DevTools 的 Rendering 面板观察图层变化。
