navigator.maxtouchpoints 是最直接的触控能力判断依据，但仅反映硬件是否支持多点触控，无法识别用户当前输入方式；应结合 matchmedia("(hover: none) and (pointer: coarse)") 等行为线索动态判断交互意图，并做好 safari 不支持、pwa 加载时机、服务端 ua 注入等兜底。
navigator.maxTouchPoints 是目前最直接、语义最清晰的触控能力判断依据，但不能单独依赖它做 UI 模式切换 —— 它只回答“硬件是否支持多点触控”，不回答“用户此刻是否在用手指操作”。
为什么 navigator.maxTouchPoints 值大于 0 就大概率是触摸设备
这个属性由浏览器内核（如 Blink）从底层渲染设置中读取，比如 Chrome 的 GetMaxTouchPoints() 返回值。主流现代浏览器（Chrome/Firefox/Edge）均支持，IE 完全不支持。
值为 0 表示无触控能力；1 表示单点触控（常见于部分 Windows 笔电）；>1 表示多点触控（绝大多数手机/平板）。
注意：某些 Windows 设备可能返回 0 即使有触控屏（驱动或内核未暴露），所以它适合“大概率判断”，不适合“100% 确认”。
仅靠 navigator.maxTouchPoints 切换 UI 会出什么问题
以下情况会导致误判：
- Windows 二合一设备插着键盘、用鼠标操作时，
navigator.maxTouchPoints > 0仍为真，但用户并不需要触控优化的按钮尺寸或手势区域 - 远程桌面或虚拟机环境可能伪造该值，返回非真实硬件能力
- 部分老旧 Android WebView（如系统级 WebView 53）根本不暴露该属性，返回
undefined
所以不要写成：if (navigator.maxTouchPoints > 0) { useTouchUI() } —— 这会让桌面用户在触控本上被迫使用大间距按钮。
怎么结合 matchMedia 做更靠谱的交互意图识别
真正该响应的是“用户当前倾向的输入方式”，而不是“设备有没有触摸屏”。window.matchMedia 提供了更贴近行为的线索：
-
(hover: none) and (pointer: coarse)：表示无悬停能力 + 粗粒度指针（即手指），基本可认定为手持触控场景 -
(hover: hover) and (pointer: fine)：表示支持悬停 + 精细指针（鼠标/触控笔），适合桌面或带笔的平板 - 两者可以同时监听变化，动态切换 UI 模式，无需刷新页面
示例逻辑：
const mql = window.matchMedia('(hover: none) and (pointer: coarse)');
const isTouchIntent = mql.matches || (navigator.maxTouchPoints > 0 && !window.matchMedia('(hover: hover)').matches);
// 注意：这里用了“或”，是因为部分旧浏览器不支持 matchMedia，退而求其次用 maxTouchPoints
实际部署时容易忽略的兼容与兜底细节
navigator.maxTouchPoints 在 Safari（截至 2026 年 4 月）仍不支持，必须加 typeof navigator.maxTouchPoints !== 'number' 判断；
移动端 PWA 加载时可能尚未触发 matchMedia 回调，建议在 DOMContentLoaded 后立即检查一次；
如果服务端已知 UA（如通过 User-Agent 头），可在首屏 HTML 中注入一个 data-input-mode="touch" 属性，前端优先读取它，避免 JS 执行前的闪动。
最麻烦的不是检测逻辑本身，而是“检测时机”和“检测组合”——单一信号永远有盲区，关键在于分层兜底，而不是找一个“银弹”。
