移动端:hover失效的根本原因是触控无“悬停”物理状态，浏览器无法可靠判断用户意图；应改用ontouchstart/ontouchend动态切换is-hovered类，并保留.btn:hover,.btn.is-hovered双兼容写法。
移动端 :hover 失效的根本原因
iOS 和 Android 主流浏览器（Safari、Chrome for Android）在触控设备上对 :hover 的支持是“延迟触发且仅限于可点击元素”，且多数情况下首次触摸后才激活，之后不会持续响应——这不是 bug，而是规范行为。根本原因是：触控没有“悬停”这一物理状态，浏览器无法可靠判断用户是否“正准备点击”还是“只是划过”。
- 非
<a></a>、<button></button>、role="button"等具有隐式或显式cursor: pointer或tabindex的元素，:hover几乎不会触发 - iOS Safari 甚至会在页面加载后主动禁用所有
:hover样式，除非用户真正点击过一次页面（触发“touch start → hover → click”链） - 单纯加
cursor: pointer在移动端无效，CSS 中该声明会被忽略
用 ontouchstart 模拟 hover 类名切换
最轻量、兼容性最好的方案是放弃依赖 CSS 伪类，改用 JavaScript 监听触控事件，在元素上动态增删 class，再用 CSS 对应类名定义样式。
- 给目标元素添加
data-hoverable属性（便于批量绑定，也避免污染语义） - 在
ontouchstart中立即添加is-hovered类（注意：不用onmouseover，它在移动端不可靠） - 同时监听
ontouchend或ontouchcancel移除该类，防止状态残留 - CSS 中用
.my-btn.is-hovered替代.my-btn:hover
element.ontouchstart = () => element.classList.add('is-hovered');
element.ontouchend = () => element.classList.remove('is-hovered');
element.ontouchcancel = () => element.classList.remove('is-hovered');
⚠️ 注意：不要用 onclick 触发，它有约 300ms 延迟；也不要只监听 ontouchstart 不清理，否则用户滑动页面时元素会一直保持“悬停态”。
避免重复绑定与内存泄漏
如果页面动态插入大量可悬停元素（如列表项、卡片），手动逐个绑定事件效率低且易漏清理。
立即学习“前端免费学习笔记（深入）”；
使用事件委托：在父容器上监听
touchstart，通过event.target.matches('[data-hoverable]')判断目标添加类时用
event.target.classList.toggle('is-hovered', true)，移除时用toggle(..., false)或直接remove若使用框架（React/Vue），确保在组件卸载/销毁时解绑事件（原生 JS 中可用
removeEventListener，但委托模式下通常只需绑定一次）不要给每个元素都写独立的
ontouchstart，尤其在innerHTML批量渲染后遍历 DOM 绑定——性能差且难维护不要在
touchmove中反复 toggle 类，这会导致滚动卡顿
要不要保留桌面端 :hover？
要，而且必须保留。现代混合设备（如带触控屏的 Windows 笔记本、iPad 配妙控板）可能同时具备鼠标和触控能力。
- 写法上采用并列选择器：
.btn:hover, .btn.is-hovered { ... } - 不要用媒体查询限制
:hover仅在hover: hover设备生效（@media (hover: hover)），因为部分安卓 Chrome 会错误报告支持 hover，导致触控时意外触发 - 如果样式差异大（比如悬停时展开子菜单），需额外考虑触控优先逻辑：触控设备上应默认展开或改用点击触发，而非模拟悬停
iOS 上长按仍可能触发 :hover，但这属于不可控、不一致的行为，不能作为功能依据。真实交互逻辑必须由 JS 显式控制。
