移动端:hover基本不可靠，因触控设备无悬停概念；浏览器仅短暂模拟且易失效，需用touchstart/touchend配合is-hovered类模拟，并分层处理鼠标与触控兼容性。
移动端为什么 :hover 基本不可靠
因为绝大多数触控设备（iOS/Android）没有“悬停”这个交互概念：手指点下去就是激活，抬起来才是触发点击，中间不存在稳定的“悬停态”。浏览器为了兼容旧样式，会在第一次触摸后短暂触发 :hover（比如 Safari 会延迟约 300ms 后应用），但紧接着焦点切换或页面滚动就会让它失效——这不是 bug，是规范行为。
更麻烦的是，Chrome for Android 从 80+ 版本起默认禁用非关键 :hover 样式，除非元素同时有 ontouchstart 或声明了 touch-action；iOS 则只在极少数场景（如带 cursor: pointer 的链接）下模拟一次。
用 touchstart + touchend 模拟悬停状态
核心思路是：用 JS 在元素上动态添加/移除一个类（比如 is-hovered），再让 CSS 基于该类定义视觉反馈。这比监听 click 更准确，因为 touchstart 立即响应，用户还没抬手就能看到反馈。
- 给需要悬停效果的元素加
touchstart事件，添加is-hovered类 - 监听
touchend或touchcancel，移除该类 - CSS 中用
.element.is-hovered替代.element:hover - 为避免误触发，建议加
{ passive: false }并阻止默认行为（尤其在scrollable容器内）
element.addEventListener('touchstart', e => {
e.preventDefault();
element.classList.add('is-hovered');
}, { passive: false });
element.addEventListener('touchend', () => {
element.classList.remove('is-hovered');
});
兼容鼠标和触控的混合写法
如果组件要同时支持桌面端鼠标和移动端触控，不能只靠 JS 模拟——否则桌面端就失去原生 :hover 的平滑过渡和可访问性（比如键盘 focus 时也应有反馈）。推荐分层处理：
立即学习“前端免费学习笔记（深入）”；
- 保留原生
:hover样式，用于鼠标设备 - 用媒体查询
@media (hover: hover) and (pointer: fine)包裹它，确保只在支持悬停的设备上生效 - 对触控设备（
@media (hover: none) or (pointer: coarse)），启用 JS 模拟逻辑，并让 CSS 基于.is-hovered生效 - 注意：不要用
ontouchstart在全局判断是否为移动设备，iOS 17+ 和部分 Chrome 桌面版也会暴露该属性
容易被忽略的细节和坑
很多方案漏掉这几点，导致体验断层或性能问题：
-
touchstart触发后若用户滑动页面，touchend可能不触发，需监听touchcancel清理状态 - 快速连续点击多个元素时，前一个的
is-hovered类可能残留，建议用document.addEventListener('touchstart', ...)全局清理其他元素的同类名 - 如果元素本身有
cursor: pointer，某些 Android 浏览器会强制开启伪:hover，反而和 JS 冲突，建议统一移除或用cursor: default配合 JS 控制 - 动画过渡（
transition）必须写在基础选择器上（如.button），而不是仅写在:hover或.is-hovered上，否则首次触控无过渡效果
真正难的不是加个类，而是让「悬停感」在不同输入方式下保持一致且不卡顿——过渡时机、状态清理、跨设备语义对齐，这些才是落地时最常出问题的地方。
