hover动画必须配合transition才能触发，需写在默认状态中且仅对可动画属性生效；位移优先用transform而非top/left；移动端不支持:hover，应使用@media(hover: hover)隔离或改用:active/JS交互。
hover动画必须用transition才能触发
纯:hover本身不产生动画，它只是状态切换；要让属性变化“动起来”，必须配合transition声明。漏写transition是最常见的空白动画问题——鼠标悬停，样式变了，但没过渡、没缓动、像开关一样突变。
实操建议：
-
transition得写在「默认状态」里（不是:hover块里），否则第一次悬停时可能不生效 - 只对可动画的CSS属性生效：比如
color、transform、opacity可以，display、height（非0值到0值）或font-size（某些旧浏览器）容易出问题 - 别偷懒写
transition: all 0.3s——会意外动画不该动的属性，还可能拖慢渲染
transform比top/left更适合做位移动画
用top或left触发动画，浏览器要反复计算布局（layout），卡顿明显；而transform: translateY()走的是合成层（compositor），GPU加速，顺滑得多。
常见错误现象：:hover里改margin或padding，页面其他元素跟着抖动——这是重排（reflow）的典型表现。
立即学习“前端免费学习笔记（深入）”；
实操建议：
- 位移优先用
transform: translateX()、translateY()，缩放用scale()，旋转用rotate() - 如果元素原本有
position: relative且靠top微调，hover时别混用top和transform，容易行为不可控 - 想让动画更稳，加一句
will-change: transform（但别滥用，仅对频繁动画的元素）
hover动画在移动端根本不会触发
手机没有“悬停”概念，:hover在iOS Safari和多数Android浏览器里要么不触发，要么只在点击后短暂生效（伪hover），指望它做交互反馈基本靠不住。
使用场景判断：如果你的组件需要同时支持桌面和移动，别把关键动效逻辑绑死在:hover上。
实操建议：
- 用
@media (hover: hover)媒体查询包裹:hover规则，确保只在真正支持悬停的设备上加载 - 移动端交互反馈建议改用
:active（点击态）或JavaScript监听touchstart/touchend - 别用
:hover隐藏关键操作入口（比如“更多按钮”只在hover出现），这会让移动端用户找不到功能
transition-delay导致悬停响应迟钝
加transition-delay: 0.2s本意是防误触，结果用户鼠标划过菜单时，动画总慢半拍，体验像系统卡死。
性能影响：延迟本身不耗资源，但它放大了用户对“响应滞后”的感知，尤其在快速扫视导航栏时。
实操建议：
- 悬停进入（hover in）尽量不用
delay；退出（hover out）倒是可以加一点（比如transition: opacity 0.3s 0.1s），避免鼠标一挪就闪退 - 真要防误触，用JavaScript加毫秒级节流，或者用
pointer-events: none临时禁用，比硬塞delay靠谱 - 检查是否在父容器上也写了
transition——子元素hover可能被继承干扰
