:hover直接写动画卡顿是因为未声明transition导致突变，且width等属性触发布局重排；应优先用transform/opacity配合transition或@keyframes实现GPU加速动画。
伪类:hover直接写动画为什么卡顿
因为 :hover 本身不触发重绘优化，浏览器默认把它当“状态切换”而非“动画流程”。如果直接在 :hover 里写 transform: scale(1.2); opacity: 0.8; 这类属性，但没声明过渡行为，浏览器会强制在帧开始时突变，造成跳变或掉帧。
- 没有
transition时，:hover是即时生效的，不是渐进过程 - 部分属性（如
width、height、margin）触发布局重排（reflow），比transform和opacity慢一个数量级 - 低性能设备或复杂 DOM 下，未优化的
:hover动画容易掉到 30fps 以下
用 transition 实现平滑 hover 动画的关键写法
必须显式声明哪些属性参与过渡、持续时间、缓动函数，并优先使用 GPU 加速属性。
button {
transform: scale(1);
opacity: 1;
transition: transform 0.25s cubic-bezier(0.34, 1.56, 0.64, 1),
opacity 0.25s ease-out;
}
button:hover {
transform: scale(1.08);
opacity: 0.92;
}
-
transition必须写在常态选择器（非:hover）上，否则鼠标移入瞬间无过渡 - 只对
transform和opacity做过渡，避免left/top/background-color等高成本属性 - 多个属性过渡要写全，不能简写成
transition: all 0.25s—— 容易意外触发重排或重绘 - 加
cubic-bezier()调整节奏比ease更可控，尤其适合入口加速+出口缓冲
需要复杂路径或分段效果时改用 @keyframes
当 hover 动画涉及三步以上变化（比如先缩放、再位移、最后旋转），或者需要不同阶段不同持续时间，transition 就不够用了，得切到关键帧。
@keyframes hoverLift {
0% {
transform: translateY(0) scale(1);
opacity: 1;
}
60% {
transform: translateY(-4px) scale(1.05);
}
100% {
transform: translateY(-2px) scale(1.03);
opacity: 0.94;
}
}
.card {
animation: hoverLift 0.35s forwards;
animation-play-state: paused;
}
.card:hover {
animation-play-state: running;
}
- 用
animation-play-state: paused/running控制播放，比animation: none切换更可靠 -
forwards确保动画停在最后一帧，否则鼠标移出后会闪回初始态 - 避免在
@keyframes里写display: none或影响布局的属性，会导致 layout thrashing - 若需反向动画（移出时也动），得额外定义
@keyframes hoverLiftOut并用 JS 监听transitionend切换
容易被忽略的兼容与性能细节
看似简单的 hover 动画，实际在移动端、旧版 Safari、或嵌套滚动容器里常出问题。
- iOS Safari 对
transform: scale()的 hover 支持极弱，需加cursor: pointer或touch-action: manipulation激活 - 父容器有
overflow: hidden且子元素动画超出边界时，某些安卓 WebView 会裁剪动画中途帧 - 大量同类型元素（如商品卡片列表）同时 hover，建议用
will-change: transform提前提示渲染层，但别滥用——它会常驻合成层，吃内存 - 不要在
:hover里调用filter: drop-shadow()做动态阴影，性能开销远高于box-shadow
