触控笔操作下 :hover 伪类被浏览器完全禁用，因 pointer 媒体特性设为 coarse 且 hover: none；CSS 无法区分鼠标与触控笔，需用 JavaScript 监听 pointerdown 的 pointerType 并动态加类处理。
触控笔设备根本不会触发 :hover
主流浏览器（Chrome、Firefox、Safari）在检测到触控笔（如 Surface Pen、Apple Pencil）输入时，会将 pointer 媒体特性设为 coarse，同时禁用所有 :hover 伪类的响应——不是“不生效”，而是根本不会匹配。这意味着哪怕你写了 a:hover { color: blue; }，在纯触控笔操作的设备上，这段样式永远不会被应用。这不是 Bug，是规范行为：W3C 明确要求 UA（浏览器）在指针精度不可靠时忽略悬停状态，避免误触发。
@media (hover: hover) 只能判断“是否支持悬停”，不能区分鼠标和触控笔
这个查询条件只返回真值当且仅当设备存在一个**可靠、精细、可悬停**的指针（比如鼠标、触控板光标），但它对触控笔一律返回 false。所以它适合做“有无悬停能力”的二分判断，但无法告诉你当前是鼠标还是触控笔在操作：
-
@media (hover: hover) and (pointer: fine)→ 鼠标/触控板（典型） -
@media (hover: none) and (pointer: coarse)→ 触摸屏手指 / 触控笔（均归为此类） -
@media (hover: none) and (pointer: fine)→ 几乎不存在；某些旧版 Windows 平板笔驱动可能偶然匹配，但不可依赖
注意：pointer: fine 不等于“支持悬停”，只是表示指针精度高；hover: hover 才是悬停能力的权威信号。
真正能区分鼠标和触控笔的方案只有 pointer + any-pointer 组合
单靠媒体查询无法实时感知当前正在使用的输入设备类型，但你可以用以下组合缩小范围并做合理降级：
-
@media (pointer: fine) and (hover: hover)→ 优先给鼠标用户加:hover样式（例如按钮放大、下划线浮现） -
@media (pointer: coarse)→ 禁用所有依赖悬停的交互反馈，改用:active或显式点击态（例如button:active { opacity: 0.7; }） -
@media (any-pointer: coarse)→ 表示“至少有一种粗粒度指针可用”（比如设备带触摸屏+触控笔），此时应默认关闭悬停依赖逻辑 - 不要尝试用
@media (pointer: fine) and (any-pointer: coarse)来“定位触控笔”——这只会匹配二合一设备（如 Surface），但无法区分当前操作是鼠标还是笔
真实场景中，触控笔和鼠标在 pointer 媒体查询里通常都报告 fine，但浏览器会根据输入事件类型（pointerdown 的 pointerType 值）决定是否启用 :hover。而这个决策完全由 UA 控制，CSS 层面不可见。
实际开发中更可靠的替代思路
与其纠结“如何用 CSS 区分鼠标和触控笔的悬停”，不如接受一个事实：CSS 没有运行时设备类型钩子。可行路径是：
- 用 JavaScript 监听
pointerdown事件，检查event.pointerType（值为"mouse"/"pen"/"touch"），然后给加对应 class（如js-pointer-mouse），再写对应 CSS - 对关键交互组件（如工具栏按钮），放弃
:hover，统一用:focus-visible+:active覆盖所有输入方式 - 触控笔用户往往也使用键盘导航，
:focus-within比:hover更健壮 - 避免“悬停即功能”，把重要操作入口（如删除、编辑）始终可见，或通过长按/右键菜单暴露
最易被忽略的一点：很多团队花时间调试 @media (hover: hover) 在 iPad 上的行为，却忘了 Safari 对触控笔的 pointerType 支持从 iOS 16.4 才开始稳定——旧版本一律报 "touch"，导致 JS 层也无法准确识别。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
