transition适合响应式状态切换，如悬停变色、点击缩放；animation适合多阶段、循环或自动播放的节奏控制，如加载旋转、心跳脉冲。
transition 适合做状态切换，animation 适合做节奏控制——选错就卡顿、跳帧、回弹，不是效果不好，是根本没走对路。
transition 只响应属性值变化，不自动播放
它不会自己动，必须靠触发：比如 :hover、:focus、JS 改 className 或直接设 style.opacity。只要属性值真变了（比如从 opacity: 1 → opacity: 0），浏览器就补间过渡；值没变，哪怕 class 已存在，也完全不动。
- 常见翻车：写
transition: all 0.3s，结果height、margin一变就触发布局重排，页面抖动 -
display、height: auto、z-index这类不可插值的属性，transition 直接忽略 - 想让过渡“只在进入时生效，离开时不执行”？不行——进出都走同一套规则，除非用 JS 拆开控制
- 性能关键：优先用
transform和opacity，它们走合成层，不触发重排重绘
animation 必须配 @keyframes，支持循环与暂停
@keyframes 是动画蓝图，animation 是启动开关。它不依赖用户动作，定义完就能跑，还能反复、倒放、暂停、填首尾帧。
- 漏掉
animation-fill-mode: forwards，动画一结束立刻弹回初始态，视觉断层明显 - 用
animation做 hover 缩放？每次移入都重头播，UI 抽搐——这是把 animation 当 transition 用了 - 多个动画叠加要逗号分隔：
animation: spin 1s, pulse 2s infinite，否则后声明的会覆盖前一个 -
animation-delay在元素进入样式计算阶段就计时，哪怕它还display: none或visibility: hidden，这点和transition-delay完全不同
哪些属性能动，哪些不能动？
两者都只对「可计算中间值」的属性生效。但实际限制更细：
立即学习“前端免费学习笔记（深入）”；
- 能安全过渡/动画的：
transform、opacity、color、background-color（重绘但不重排） - 慎用、易卡顿的：
width、height、left、top（触发布局重排） - 根本不动的：
display、z-index、font-size（部分浏览器不支持）、height: auto（无明确终点值） -
box-shadow可动画，但模糊半径大时 GPU 负担高；filter（如blur()）同理，低端设备慎用
混用 transition 和 animation 才是真实项目常态
别纠结二选一。典型分层方案：
- 用
transition处理用户操作带来的状态变化：菜单展开的max-height过渡、按钮点击反馈的transform: scale() - 用
animation实现独立节奏的视觉反馈：加载图标旋转、通知气泡脉冲、背景粒子浮动 - 注意冲突：如果同一个属性（比如
transform）同时被 transition 和 animation 控制，animation 会赢——但行为不可预测，建议避免重叠 - IE10+ 支持
@keyframes，但老 Android WebView 对cubic-bezier()解析不准，线上环境优先用ease、linear
真正容易被忽略的，是 transition-delay 和 animation-delay 的计时起点差异，以及 animation-fill-mode 缺失导致的“闪退”。这两个点，90% 的动效 Bug 都出在这儿。
