hover: hover 匹配支持且启用悬停交互的设备（如带鼠标的iPad），hover: none 表示完全不支持悬停（如iPhone）；单用 hover 不够安全，需组合 pointer: fine 和 min-width 判断，并配合 JS 控制移动端菜单展开。
hover: hover 和 hover: none 到底匹配什么设备
hover: hover 不是“有鼠标”，而是“支持悬停交互且该能力可用”；hover: none 表示设备**完全不支持悬停状态**，比如绝大多数纯触屏手机（iOS Safari、Android Chrome 默认行为）。但注意：iPad + 鼠标/触控笔、Windows 触摸平板接键盘后，可能同时满足 hover: hover 和 pointer: fine，而 iPhone 永远不会匹配 hover: hover（即使连了蓝牙鼠标，Safari 仍禁用 hover）。
为什么只写 @media (hover: hover) 还不够安全
单靠 hover 媒体特性容易误判，尤其在以下场景：
- iPad 分屏模式下视口变窄，但
hover: hover仍为 true，结果把本该收起的桌面菜单强塞进小区域 - 某些安卓平板开启“强制触摸模式”后，
hover: hover返回 false，但实际连接了鼠标——这时你禁用了所有 hover 样式，用户反而没交互反馈 - Chrome DevTools 的“Toggle device toolbar”模拟器默认不启用 hover 模拟，调试时容易误以为规则失效
更稳妥的做法是组合判断：@media (hover: hover) and (pointer: fine) and (min-width: 768px)。三者同时成立，才启用完整桌面级 hover 样式。
移动端点击菜单和桌面悬停菜单共存的 CSS 写法
常见错误是直接给 nav ul li:hover > ul 写样式，导致移动端点一下就闪出菜单又立刻消失。正确做法是用媒体查询把 hover 样式“锁住”在支持设备上：
立即学习“前端免费学习笔记（深入）”；
@media (hover: hover) and (pointer: fine) {
nav ul li:hover > ul {
display: block;
}
}
/* 移动端默认隐藏子菜单 */
nav ul ul {
display: none;
}
/* 移动端通过 JS 添加 .is-open 类来显示 */
nav ul li.is-open > ul {
display: block;
}关键点：
- 不要依赖
:hover控制移动端可见性，它不可靠 -
display: none必须写在未包裹媒体查询的基础样式里，否则在不支持 hover 的设备上子菜单会意外常驻 - JS 动态切换
.is-open类时，确保只影响当前点击项，避免多个子菜单同时展开
调试时怎么快速验证 hover 媒体查询是否生效
浏览器开发者工具里不能直接“切换 hover 状态”，但可以手动触发匹配测试：
- 在控制台执行
window.matchMedia("(hover: hover)").matches，返回true表示当前环境支持悬停 - 用
window.matchMedia监听变化：const mql = window.matchMedia("(hover: hover)"); mql.addEventListener("change", e => console.log(e.matches)); - 真机调试时，iOS Safari 需在「设置 → 辅助功能 → 触控」中关闭「辅助触控」，否则可能干扰 hover 检测
最易被忽略的是：CSS 中的 hover 媒体特性检测的是**当前会话能力**，不是硬件配置。用户拔掉鼠标、切出分屏、甚至旋转屏幕都可能让 matchMedia 结果翻转——所以别把它当静态开关用。
