transition 和 @keyframes 不能混用同一属性，否则会导致卡顿、跳变或 keyframes 不触发；二者机制独立，animation 优先级更高但易冲突；应按职责分离：transition 处理简单交互反馈，@keyframes 处理多阶段复杂动画，并避免动态修改被占用的属性。
transition 和 @keyframes 不能混用同一个属性
很多人试图这样写：transition: all 0.3s，同时又用 @keyframes 动画控制 transform 或 opacity，结果发现动画卡顿、跳变，或者 keyframes 根本不触发。这是因为 transition 和 @keyframes 是两套独立的动画机制，浏览器不会自动协调它们对同一属性的控制权。
-
transition只响应属性值的「变化」（比如 class 切换、:hover、JS 修改 style），且只做起点→终点的插值 -
@keyframes是声明式时间轴，由animation属性主动触发，完全接管该属性在动画周期内的所有中间状态 - 如果一个元素同时被
transition和animation修改同一个 CSS 属性（如transform），后者优先级更高，但过渡可能被中断或产生冲突
想让 transition 和 keyframes 协同工作，必须分责
常见可靠做法是：用 transition 处理「交互反馈类」简单变化（比如 hover 时背景色渐变、边框粗细微调），用 @keyframes + animation 处理「有节奏、多阶段、需精确控制」的动效（比如弹跳入场、路径位移、循环旋转）。
- 给不同属性分工：比如
transition控制background-color，animation控制transform - 避免在动画运行中动态修改被
animation占用的属性（例如 JS 直接改element.style.transform），否则会覆盖动画效果 - 若需在动画结束后保持最终状态，务必加
animation-fill-mode: forwards
transition 触发后立即播放 keyframes 的典型写法
典型场景：点击按钮 → 先有个过渡缩放（transition），再执行一段入场动画（keyframes）。关键在于用 class 分离两个阶段，靠 JS 或伪类顺序触发。
.btn {
transform: scale(1);
transition: transform 0.2s ease;
}
.btn.animating {
transform: scale(0.95); /* 过渡起点 */
animation: popIn 0.4s ease-out 0.2s forwards; /* 延迟 0.2s 后启动 keyframes */
}
@keyframes popIn {
0% { transform: scale(0.95); }
70% { transform: scale(1.05); }
100% { transform: scale(1); }
}- 第一次 class 切换（加
.animating）触发transition缩放至 0.95 -
animation-delay: 0.2s确保它等过渡结束才开始 -
animation-fill-mode: forwards保证动画停在scale(1)，不回退 - 注意：不要在
@keyframes里再写transition，无效
容易被忽略的兼容性与重绘陷阱
即使语法正确，动画也可能掉帧或闪烁，尤其在移动端。根本原因常是浏览器被迫进行昂贵的 layout 或 paint，而非利用 GPU 加速的 composite。
立即学习“前端免费学习笔记（深入）”；
- 只对能触发硬件加速的属性做动画：优先用
transform和opacity；避免动画width、height、left、top等会触发布局计算的属性 - 强制开启 GPU 加速：在动画元素上加
transform: translateZ(0)或will-change: transform（但别滥用，will-change本身有开销） -
transition的ease类函数（如cubic-bezier(.25,.46,.45,.94)）和@keyframes中的animation-timing-function行为一致，但后者可逐帧定义，更灵活
真正难的是判断哪段交互动效该用 transition、哪段该拆成 keyframes——这取决于是否需要中间状态控制、是否要循环、是否依赖 JS 动态参数。写完记得在真机上点几次，看有没有卡顿或意外回退。
