@media (hover: none) and (pointer: coarse) 这组媒体查询条件，通常可以视为区分触控设备最稳妥、最实用的 CSS 写法。它判断的并不是“设备是否支持触摸”这种过于宽泛的概念，而是更准确的交互状态：当前主要输入方式为手指触控，并且设备本身不具备悬停能力。主流浏览器如今都已支持这套触控判断方案，但在书写时一定要特别注意，条件需要连写且不能夹空格，:coarse 这个值也不能省略。若想实现更稳定的动态适配，建议再结合 JavaScript 监听 pointerdown 事件以及 matchMedia 的变化。
@media (hover: none) and (pointer: coarse) 是当前判断触控设备最可靠的组合
这组 CSS 媒体查询能够更准确识别“当前主要输入是手指触控，且没有悬停能力”的实际状态，Safari 14.1+、Chrome 51+、Firefox 62+ 均已完整支持。它关注的不是“有没有触摸屏”，而是“此时此刻是否只能依赖点按交互”——这才是前端交互适配和响应式体验优化的关键依据。
常见错误场景包括：只使用 @media (hover: hover) 来判断桌面端，结果 Surface Pro 在合盖或触控操作时依然被误判；或者仅用 @media (max-width: 768px) 识别移动端，把带触控屏的 Windows 笔记本当作手机处理，最终导致下拉菜单、悬浮交互无法正常展开。
@media (hover: none) and (pointer: coarse)必须采用连写形式，中间不能有空格（如(hover: none)and(pointer: coarse)是合法写法，而加入空格后，部分旧版 Safari 可能出现兼容问题）- 不要遗漏
: coarse这个明确的值，像@media (pointer)或@media (pointer: )这样的写法都会使整条规则失效 - 该组合不会匹配 iPad 连接妙控板或鼠标后的状态——这恰好说明它响应的是当前真实输入模式，而不是硬件层面的静态属性
@media (hover: hover) and (pointer: fine) 才适合启用 :hover 样式
所有依赖悬停的交互效果，例如 a:hover、.dropdown:hover .menu，都应该严格限制在这个媒体查询条件内使用。这样不仅可以排除纯触控场景，也能避免 Surface 等混合设备在触控模式下产生误判，更符合 CSS hover 适配的最佳实践。
为什么不能只依赖 @media (hover: hover)？原因在于 iPadOS 和 ChromeOS 这类系统，只要设备“具备悬停能力”（哪怕只是曾连接过一次鼠标），就可能持续返回 hover: hover，而这与用户当前实际使用的是手指还是鼠标并不完全一致。
@media (hover: hover) and (pointer: fine)里的pointer: fine是核心限制条件，确保只有鼠标、触控笔等高精度输入设备才会触发相关样式- Android WebView 4.4 及更早版本不支持
pointer，这时需要降级到@media (max-width: 768px)或配合 JavaScript 检测，但应仅用于兼容兜底，而不是作为主判断逻辑 - 不要在该媒体查询中设置过短的过渡动画时长（如
transition: all .08s），鼠标操作虽然反应迅速，但一旦触控设备误入该分支，动画体验往往会显得生硬突兀
JavaScript 必须补足 CSS 的动态适配盲区
仅靠 CSS 媒体查询，并不能捕捉“用户刚刚从鼠标操作切换为手指触控”的那个瞬间。更稳妥的前端适配方案是：在首次触发 pointerdown 且 event.pointerType === 'touch' 时，主动将当前状态标记为触控模式；同时再结合监听 window.matchMedia('(hover: none)').matches 的变化。相比轮询，这种方式性能更高，也更适合真实交互场景。
一个非常常见的误区是：使用 'ontouchstart' in window 来判断触摸设备。事实上这种做法并不可靠——Chrome 桌面版、Linux 浏览器，甚至部分 Electron 应用都可能返回 true，但这和设备是否真的具备物理触控能力并没有直接关系。
- 优先通过
window.matchMedia('(hover: none) and (pointer: coarse)')获取初始状态，而不是依赖na vigator.maxTouchPoints（已废弃）或 UA 字符串识别 - 不要在给
body添加touch-modeclass 后，再维护大量.touch-mode .tooltip之类的样式分支——这样不仅会让 CSS 逻辑失控，也无法及时响应系统级输入设备切换 - 如果只是临时禁用某个元素的 hover 行为，直接使用
element.style.pointerEvents = 'none'往往比切换 class 更轻量，也能更快生效
粗粒度指针（pointer: coarse）并不等于“就是手机设备”
@media (pointer: coarse) 匹配的是输入精度，而不是设备类型本身。像 Surface Pro、Chromebook，甚至部分游戏手柄设备，都可能触发这一条件。如果单独把它当作移动端判断标准，就容易造成按钮在桌面触控屏上被不必要地放大，却在 iPad 连接键盘后失去预期效果。
最典型的误用方式，就是拿它来控制整页布局切换。更合理的做法，是仅针对交互密度进行微调，例如把按钮的 min-height 提升到 48px，把 padding 增加到 12px，并去除依赖纯 :hover 触发的二级菜单，这才符合触控端体验优化的方向。
- 尽量避免在
@media (pointer: coarse)条件下启用transition，因为手指操作的开始与结束边界并不总是明确，过渡动画容易显得拖沓或卡顿 - 如果业务场景必须区分“纯触控设备”和“混合输入设备”，较可行的方案只有组合
(hover: none) and (pointer: coarse)+ JavaScript 监听pointerdown+ 服务端 UA 辅助判断（仅作为首次加载时的兜底策略） - 旧版 Android WebView 不支持
pointer特性，caniuse 显示整体兼容率约为 94%，剩余约 6% 的场景更建议使用@media (max-width: 480px)做视觉层面的降级，而不是功能层面的降级
真正影响 CSS 媒体查询是否生效的关键，不在于你写了多少规则，而在于是否理解浏览器上报的是“当前输入能力”，而不是“设备出厂配置”。例如 iPad 一旦接入鼠标，@media (hover: hover) and (pointer: fine) 就会立即接管相关样式。因此，你编写的前端样式和交互逻辑必须能够承受这种动态切换，而不能假设“触控模式永远固定不变”。
