触摸屏上 :hover 失效是浏览器策略而非 bug；现代移动浏览器为防误触默认降级 :hover，应优先用 @media (hover: hover) 隔离环境，避免依赖 :hover 控制功能。
触摸屏上 :hover 突然失效或延迟触发？不是 bug，是浏览器策略
现代移动浏览器（Chrome Android、Safari iOS）默认对 :hover 做了降级处理：触摸操作不会触发 :hover，除非用户明确“悬停”——但手指没法悬停。这不是 CSS 写错了，而是 UA 为避免误触和性能损耗主动忽略部分 :hover 样式。
常见现象包括：按钮在 iPad 上点按无高亮、下拉菜单不展开、tooltip 不出现。别急着加 JS 模拟，先确认是否真需要 :hover —— 触摸设备的交互范式本来就不依赖悬停。
- 只用
:hover控制可见性（如display: none → block）在触摸设备上基本不可靠 - Safari iOS 会延迟约 300ms 才触发
:hover（模拟“悬停”判断），且仅限于第一次触摸后的短暂窗口期 - Chrome Android 已默认禁用非
<a></a>元素上的:hover样式应用
用 @media (hover: hover) 精准隔离鼠标/触摸环境
这是最干净的解法：CSS 媒体查询能识别设备是否支持可靠悬停。它比 pointer: coarse 更直接对应 :hover 行为。
典型写法是“默认给触摸优化，再用 @media 覆盖鼠标场景”：
立即学习“前端免费学习笔记（深入）”；
button {
background: #eee;
}
@media (hover: hover) {
button:hover {
background: #ccc;
}
}-
(hover: hover)表示设备有精确指针（鼠标/触控笔）且支持稳定悬停；(hover: none)表示不支持（绝大多数手机/平板） - 不要写成
@media (hover: hover) and (pointer: fine)—— 多余，hover: hover已隐含pointer: fine - 注意 Safari 15.4+ 才完全支持该特性，旧版 iOS Safari 会直接忽略整个媒体块（安全降级）
JavaScript 检测触摸并切换 class，慎用但有时绕不开
当必须动态控制状态（比如菜单需点击展开、再点击收起），而 CSS 媒体查询不够用时，JS 是补充手段。关键不是监听 touchstart，而是区分交互意图。
错误做法：给所有元素加 touchstart 监听器并立刻加 is-hovered 类——这会让所有触摸都“模拟悬停”，违背直觉。
- 只在真正需要悬停反馈的组件内处理，例如带子菜单的
nav-item - 优先用
click+ 状态标记（aria-expanded或自定义data-state），而非强行复现:hover - 避免同时绑定
mouseenter和touchstart——会导致桌面端重复触发；用if ('ontouchstart' in window)分支更稳妥
伪类组合（:hover:focus）在触摸设备上几乎无效
有人试图用 button:hover:focus 让触摸后获得焦点的按钮显示悬停态，但实际效果极差：触摸点击后焦点虽存在，:hover 却未激活，组合伪类直接失效。
更现实的路径是放弃 :hover 参与逻辑，改用可聚焦元素的 :focus 或显式状态类：
button:focus {
outline: 2px solid #007aff;
}
button.is-active {
background: #007aff;
}-
:focus在触摸设备上依然有效（尤其配合屏幕阅读器或外接键盘） - 如果 UI 需要“按下态”，用
:active—— 它在触摸和鼠标下都可靠触发（注意：iOS Safari 默认禁用:active，需加* { -webkit-tap-highlight-color: transparent; }） - 别依赖
:hover做功能开关（比如控制弹层显隐），那本质是把鼠标交互模型硬套到触摸上
真正麻烦的不是怎么让 :hover 在手机上工作，而是得想清楚：这个悬停反馈，在手指点按的流程里，到底有没有对应的操作意义。很多时候删掉它，反而更一致。
