navigator.maxTouchPoints 不是判断是否为手机的依据，而是反映当前环境是否报告多点触控能力的信号，必须与 matchMedia('(hover: none) and (pointer: coarse)') 配合使用才能准确识别用户操作意图。
navigator.maxTouchPoints 不是“是不是手机”的开关，而是“当前环境是否报告了多点触控能力”的信号。它必须和 matchMedia 配合使用，否则切换 UI 模式大概率会错配到桌面触控本、远程桌面或禁用触摸的 Windows 设备上。
为什么只看 navigator.maxTouchPoints > 0 就切 touch UI 是危险的
这个值反映的是浏览器从系统获取的「当前激活的触摸路径能力」，不是物理屏幕有没有触摸层。常见误判场景包括：
-
navigator.maxTouchPoints返回 5，但用户正用鼠标在 Surface Pro 上操作——UI 却放大按钮、禁用 hover，体验突兀 - Chrome 远程桌面或某些企业定制 ROM 下，该值恒为 0，即使真有触控屏，UI 也完全不响应手指操作
- 旧版 Safari（iOS 12 及更早）根本不暴露
maxTouchPoints，返回undefined，直接报错或跳过逻辑 - 部分 Windows 笔电驱动未上报，
maxTouchPoints === 0，但手指确实能点屏幕
怎么用 matchMedia('(hover: none) and (pointer: coarse)' 做行为级判断
这才是决定 UI 是否该“降级”的关键依据：它不问设备有没有触摸能力，而问「用户此刻倾向怎么操作」。满足这两个条件，基本可认定是手持触控场景：
-
hover: none→ 主输入设备不支持悬停（手指没有 hover，鼠标/触控板有） -
pointer: coarse→ 主指针精度低（手指 vs 鼠标/笔）
实操建议：
- 不要只在页面加载时查一次，用
matchMedia().addEventListener('change', handler)监听动态切换（比如拔掉键盘、切平板模式） - 避免在 SSR 中依赖它——
matchMedia是纯客户端 API，服务端拿不到 - 兜底逻辑要分层：
if (mql.matches) { touchIntent = true } else if (navigator.maxTouchPoints > 0) { touchIntent = !window.matchMedia('(hover: hover)').matches }，兼顾旧浏览器兼容性
UI 模式切换不能只加 class，得动交互链路
检测只是起点，真正影响体验的是事件绑定、样式响应和交互反馈的协同变化。粗暴替换 click 为 touchstart 往往引发问题：
- 移除所有
mouseenter/mouseleave监听器，防止在触摸设备上触发无效 hover 状态 - 用
{ passive: false }绑定touchstart，否则滚动拦截可能失效（尤其在需要preventDefault()的手势中） - 禁用依赖
:hover的下拉菜单、工具提示；改用显式点击展开（aria-expanded+ JS 控制） - 检查
scroll-behavior: smooth在触摸滚动中是否卡顿，必要时回退为auto
示例片段：
const mql = window.matchMedia('(hover: none) and (pointer: coarse)');
const updateTouchMode = () => {
const isTouchIntent = mql.matches;
document.body.classList.toggle('touch-mode', isTouchIntent);
if (isTouchIntent) {
document.querySelectorAll('[data-hover-dropdown]').forEach(el => {
el.removeAttribute('data-hover-dropdown');
});
}
};
mql.addEventListener('change', updateTouchMode);
updateTouchMode();
兼容性与 fallback 必须写进主逻辑，不能靠注释
现实环境里，maxTouchPoints 在 IE 完全不可用，Safari 旧版返回 undefined，某些 WebView 根本不暴露。这时候仅靠它做分支就是埋雷：
- 先检查
"maxTouchPoints" in navigator，再读值，避免Cannot read property 'maxTouchPoints' of undefined - fallback 到
'ontouchstart' in window是合理选择，但它只是「有触摸事件监听能力」，不代表用户正在用手指操作，所以只能作为辅助线索，不能替代matchMedia - 若两者都不可用（如极老 Android WebView），应默认走「通用模式」：保留 hover 样式但不依赖它驱动交互，事件监听同时注册
click和touchstart（注意去重和 300ms 延迟处理）
最常被忽略的一点：混合设备的「运行时状态变化」比「首次加载判断」重要得多。用户插拔键盘、切显示器、开闭触控设置，都会让交互意图翻转——而这些，只有 matchMedia 的 change 事件能可靠捕获。
