navigator.maxtouchpoints > 0 仅表明硬件支持多点触控，非实时操作意图；应结合 matchmedia('(hover: none) and (pointer: coarse)') 动态判断用户当前输入方式，并监听 change 事件以响应设备切换。
navigator.maxTouchPoints 值大于 0 是触控能力的强信号，但不能直接等价于“当前用户在用手指操作”——它只说明硬件支持多点触控，不反映实时交互意图。
为什么navigator.maxTouchPoints > 0只能作“大概率判断”
这个值由浏览器内核（如 Blink 的 GetMaxTouchPoints()）从系统渲染层读取，主流 Chrome/Firefox/Edge 都支持，IE 完全不支持。值为 0 表示未报告触控能力；1 表示单点（部分 Windows 笔电）；>1 基本对应手机/平板。
但以下情况会让它失准：
- Windows 二合一设备插着键盘、正用鼠标操作时，
navigator.maxTouchPoints仍可能返回 2 或更高 - 远程桌面、虚拟机或企业定制 ROM 可能伪造该值，或完全屏蔽 API（返回
undefined） - 某些老旧 Android WebView（如系统级 WebView 53）根本不暴露该属性
别单独用navigator.maxTouchPoints做 UI 切换
写成 if (navigator.maxTouchPoints > 0) { useTouchUI() } 会出问题：桌面用户在触控本上被迫放大按钮间距，触控笔用户被误判为手指操作，PWA 启动初期该值可能还未就绪。
更稳妥的做法是把它当作线索之一，而非判决依据：
- 优先监听
window.matchMedia('(hover: none) and (pointer: coarse)')—— 这个组合才真正指向“当前主输入方式是手指” - 当
matchMedia不可用（如旧浏览器），再回退到navigator.maxTouchPoints > 0 - 避免在
DOMContentLoaded阶段立即执行判断，建议等load或首次交互后触发
怎么结合matchMedia做动态响应
(hover: none) 表示无悬停能力（鼠标/触控板有 hover，手指没有）；(pointer: coarse) 表示粗粒度指针（即手指）。两者同时成立，基本可认定为手持触控场景。
示例逻辑：
const mql = window.matchMedia('(hover: none) and (pointer: coarse)');
const isTouchIntent = mql.matches || (
"maxTouchPoints" in navigator &&
navigator.maxTouchPoints > 0 &&
!window.matchMedia('(hover: hover)').matches
);
if (isTouchIntent) {
document.body.classList.add("touch-mode");
}
注意：要监听 mql.addEventListener('change', handler)，因为用户可能在运行中插拔键盘、切换输入设备。
容易被忽略的兼容性细节
不是所有环境都能拿到可靠值：
- Safari 在某些 PWA 场景下不暴露
navigator.maxTouchPoints，需用"ontouchstart" in window回退（但注意 polyfill 可能污染该属性） -
navigator.msMaxTouchPoints是 IE 专属，已淘汰，无需主动兼容 - 服务端渲染（SSR）时该 API 完全不可用，必须在客户端 hydration 后判断
- 值为 0 时，不能反推“是 PC”，只能说明“当前环境未报告触控能力”
真正的难点不在读取数值，而在理解：你不是在检测设备，而是在推测用户此刻想怎么操作——这需要多条线索交叉验证，且必须允许运行时变更。
