最可靠方式是使用matchMedia("(hover: hover)").matches检测输入能力，而非UA或touchstart；CSS中用@media (hover: hover)包裹:hover规则，JS中仅在匹配时绑定mouseenter/mouseleave，并监听change事件响应动态变化。
检测设备是否支持hover伪类
浏览器本身不提供直接判断“当前设备是否支持hover”的API，但可以通过matchMedia查询(hover: hover)媒体特性——它在鼠标指针可悬停（如桌面浏览器）时返回true，在纯触控设备（如iOS Safari、Android Chrome默认模式）中返回false。
注意：这个特性检测的是**输入能力**，不是屏幕尺寸或UA字符串。哪怕你在平板上接了蓝牙鼠标，现代浏览器也会正确报告(hover: hover)为true。
-
matchMedia("(hover: hover)").matches是最可靠、被广泛支持的判断方式（Chrome 38+、Firefox 30+、Safari 9+、Edge 12+） - 不要用
navigator.userAgent识别“PC/手机”，它既不可靠又容易过期 - 不要监听
touchstart后禁用hover样式——这会破坏混合输入设备（如二合一笔记本）的体验
CSS中条件性启用hover样式
直接在CSS里用@media (hover: hover)包裹hover规则，是最干净的做法。这样CSS引擎只在支持hover的环境下解析并应用这些样式，完全避免无效规则干扰渲染。
button {
background: #ccc;
}
@media (hover: hover) {
button:hover {
background: #007bff;
}
}
- 写在
:hover外面的@media块，能确保触控设备完全忽略该规则，不参与样式计算 - 别写成
@media (hover: hover) and (pointer: fine)——pointer: fine虽常伴随hover，但不是必要条件，且兼容性更差（Safari 15.4+才支持） - 如果用了CSS-in-JS（如Emotion、Styled Components），需确认其支持媒体查询嵌套；否则得退回到JS中动态插入class
JavaScript中按需加载hover交互逻辑
光关掉CSS hover不够——如果JS里还绑了mouseenter/mouseleave，在触控设备上会触发意外行为（比如空转事件监听、误触发tooltip）。应该只在(hover: hover)为true时才注册这些监听。
立即学习“前端免费学习笔记（深入）”；
if (matchMedia("(hover: hover)").matches) {
button.addEventListener("mouseenter", handleHoverIn);
button.addEventListener("mouseleave", handleHoverOut);
}
-
mouseenter/mouseleave在触控设备上**不会触发**，但监听器仍存在、占用内存、可能干扰事件委托逻辑 - 别用
mouseover/mouseout替代——它们冒泡且触发频繁，问题更大 - 如果组件已挂载，又需要响应系统级hover能力变化（比如用户外接鼠标），记得监听
matchMedia的change事件并更新监听状态
移动端fallback和渐进增强的边界
很多人以为“加个@media (hover: hover)就万事大吉”，其实漏掉了关键一环：触控设备上，用户仍然需要等效操作路径。hover样式通常暗示“可交互”，那触控下就得有明确的tap反馈或可见状态提示。
- 按钮至少要有
:active样式（哪怕只是opacity: 0.8），否则触控点击像没反应 - 带hover tooltip的元素，必须提供tap可展开的替代方案（比如加个
aria-haspopup+ 点击toggle） - 别把hover当作唯一入口——例如仅靠
nav > ul:hover > li展开下拉菜单，触控设备将彻底无法访问子项
hover支持与否不是二值开关，而是输入模型差异。真正难处理的，是那些同时连接键盘、鼠标、触摸屏的设备，它们的matchMedia("(hover: hover)")可能随输入方式动态变化——这时候样式和JS状态同步才是最易出错的地方。
