移动端无:hover状态是交互模型差异所致，非浏览器缺陷；应使用@media (hover: hover) and (pointer: fine)精准启用悬停样式，否则退化为:active/:focus反馈，并避免干扰JS焦点逻辑与可访问性。
移动端根本不存在:hover状态
这不是浏览器“没实现好”，而是交互模型的底层差异：触摸设备没有悬停（hover）这个概念。iOS 和 Android 浏览器在 touchstart 后最多短暂模拟一次 :hover，随后立即清除，且该行为不可靠、被大量 UA 策略禁用。你写的 .btn:hover { background: blue; } 在手机上几乎从不生效——不是代码错，是它本就不该在那里运行。
@media (hover: hover) 是唯一靠谱的检测方式
别用 max-width 或 UA 字符串判断设备类型，Surface、iPad Pro 这类二合一设备既支持触控又支持鼠标，靠尺寸或 UA 会误判。真正有效的方案是：
- 用
@media (hover: hover) and (pointer: fine)包裹所有悬停样式，只在明确支持精细指针的设备上启用 - 默认状态下（即不满足该媒体查询时），让按钮、卡片等保持静态样式，或退化为
:active/:focus反馈 - 例如：
.card { transition: transform .2s; } @media (hover: hover) and (pointer: fine) { .card:hover { transform: translateY(-2px); } }
悬停样式残留会导致移动端点击异常
常见现象：在手机上轻点下拉菜单项，.dropdown:hover .dropdown-menu { display: block; } 瞬间触发，同时 <a href="..."> 被激活，页面跳转，菜单根本来不及展开。更隐蔽的问题是：
- CSS 悬停规则若未被媒体查询包裹，可能干扰 JS 的 focus/blur 状态管理
- 某些安卓 WebView 会因悬停样式触发不必要的重排（reflow），拖慢点击响应
- 屏幕阅读器用户依赖明确的焦点路径，而无条件的 :hover 会掩盖真正的可聚焦逻辑
禁用悬停不只是“去掉动画”
它本质是做一次交互契约重申：哪些反馈必须存在（如点击态 :active）、哪些只是锦上添花（如悬停抬升）、哪些必须由 JS 动态控制（如 aria-expanded 同步）。尤其要注意 box-shadow 和 transform 同时过渡带来的掉帧问题——低配安卓机上，一个未加 will-change: transform 的悬停卡片，滑动时就可能卡顿。真正要禁的，从来不是“效果”，而是“不该出现的假设”。
立即学习“前端免费学习笔记（深入）”；
