该用 transition 而非 @keyframes 动画时：只需“有来有回”的状态切换，如 hover 变色、class 切换展开菜单；它依赖触发条件，仅定义起止态，自动反向过渡且性能更优。
什么时候该用 transition，而不是 @keyframes 动画？
当你只需要“有来有回”的状态切换时，transition 是更轻、更可控的选择。它不自己动，只等属性值变了才开始补间——比如鼠标移上去变色、JS 切换 class 后展开菜单。
- 必须有明确的触发条件（
:hover、:focus、class 变更、内联样式修改） - 只能定义起始和结束两个状态，中间过程由浏览器自动计算，无法插入 50% 的停顿或加速点
- 反向变化也自动过渡（比如鼠标移出，会原路缩回去），但不能设“只正向执行一次”
- 性能友好：配合
transform和opacity使用时，基本走 GPU 加速
常见误用：transition: all 0.3s —— 一 hover 就 width、height、margin 全动，触发重排，卡顿且不可预测。
为什么 @keyframes + animation 不可替代？
因为它是“自成一套”的动画系统，能描述完整的时间序列。页面一加载就能跑，不用等用户操作；可以循环、暂停、反向、精确控制每一帧。
-
@keyframes必须用百分比（0%、50%、100%）或from/to定义关键帧，不能写 JS 表达式或变量 -
animation-fill-mode: forwards很关键——否则动画播完就“弹回”初始样式，常被忽略 -
animation-delay在元素进入样式计算阶段就开始倒计时，哪怕它还display: none或visibility: hidden，这点和transition-delay行为完全不同 - 多个动画叠加要写成逗号分隔：
animation: slide 0.4s, fade 0.2s 0.1s，否则后声明的会覆盖前一个
transition 和 animation 的参数差异容易踩哪些坑？
两者看起来都有 duration、delay、timing-function，但语义和行为完全不同。
立即学习“前端免费学习笔记（深入）”；
-
transition-delay：只在触发条件满足（如鼠标进入）那一刻才开始计时；若触发前元素不可见，延迟不累积 -
animation-delay：只要样式生效（哪怕元素还在 DOM 中但display: none），延迟就开始走，可能造成“动画已播完才显示元素”的错觉 -
transition没有iteration-count或direction，没法设无限循环或交替播放 -
animation支持animation-play-state: paused，配合 JS 控制启停更可靠；transition只能靠移除 class 或重置样式“中断”，不可靠
性能敏感场景下怎么选？
优先保帧率，不是功能越全越好。
- 适合用
transition的：按钮悬停缩放、输入框 focus 边框高亮、折叠面板展开/收起（只涉及max-height+opacity） - 必须用
animation的：加载旋转图标（需infinite）、路径运动（如小球沿贝塞尔曲线移动）、多属性异步变化（先位移再旋转再变色） - 都避免对
width、height、left、top做动画——它们触发布局重排，卡顿明显；改用transform: translate()替代
最常被忽略的一点：transition 等着别人变，animation 自己决定什么时候动。选错，不是效果不对，就是时机失控。
