navigator.maxTouchPoints 不可靠，无法准确识别触控能力；应通过事件监听（如 touchstart、pointerdown）动态检测真实输入方式并实时调整 UI。
navigator.maxTouchPoints 不能准确识别混合触控设备，也不适合用于自动切换 UI 交互模式。它只返回浏览器声称支持的最大并发触点数，而这个值在多数现代桌面浏览器中被硬编码为 0（Chrome/Firefox/Edge 默认）、1（Safari macOS）或任意固定值（如 5），与真实硬件能力完全脱钩。
navigator.maxTouchPoints 在实际设备上的表现不可靠
- Windows 笔记本带触摸屏 + 触控板：Chrome 返回
0，即使物理支持 10 点触控 - iPadOS Safari：返回
1（历史遗留行为），但实际支持 5+ 点 - macOS 触控板 + 外接触控屏：Safari 可能返回
1，无法区分输入源类型 - 部分 Android WebView 或鸿蒙
Webview未实现该属性，直接返回undefined
这意味着你不能靠它判断“当前用户是否在用手指点屏幕”，更无法区分是纯触控设备、混合设备（触控屏+鼠标）、还是仅鼠标设备。
混合设备的真实检测应基于事件能力探测
真正可行的策略是监听并观察用户首次交互事件类型，结合 TouchEvent 和 MouseEvent 的可用性与触发行为：
- 使用
'ontouchstart' in window判断浏览器是否支持触控事件（注意：这不等于设备有触控屏，只是 API 可用） - 监听
touchstart且event.touches.length > 0，确认用户实际使用了触控 - 同时监听
mousedown，若在无touchstart触发前提下发生，则倾向为鼠标/触控板操作 - 对于混合场景（如触控屏上用触控板操作），需额外观察
event.pointerType（如果使用PointerEvent）
推荐初始化逻辑：
let inputMode = 'unknown';
const detectInput = (e) => {
if (e.type === 'touchstart' && e.touches.length > 0) {
inputMode = 'touch';
} else if (e.type === 'pointerdown' && e.pointerType === 'mouse') {
inputMode = 'mouse';
} else if (e.type === 'pointerdown' && e.pointerType === 'pen') {
inputMode = 'pen';
}
};
window.addEventListener('touchstart', detectInput, { once: true });
window.addEventListener('pointerdown', detectInput, { once: true });
这样比任何静态 UA 或 navigator 属性都贴近真实用户意图。
自动调整 UI 交互模式的关键不是“设备类型”，而是“当前交互流”
- 触控操作天然需要更大热区、更少悬停依赖、禁用
:hover样式降级 - 鼠标操作可启用右键菜单、拖拽反馈、精确 hover tooltip
- 混合设备（如 Surface Pro）可能在一次会话中切换输入方式，UI 必须支持运行时响应
不要在页面加载时就固化交互模式。应该：
- 将按钮热区、滚动行为、长按延迟等封装为可动态更新的模块
- 使用 CSS
@media (pointer: coarse)和@media (hover: hover)做基础分层 - 在 JS 中监听
pointerdown并根据e.pointerType实时切换状态管理逻辑 - 避免用
navigator.maxTouchPoints做条件分支，它既不反映当前输入，也无法预测后续行为
navigator.maxTouchPoints 是一个已被实践证伪的指标。真正影响 UI 行为的，是用户此刻怎么点、滑、按——而不是浏览器声称它“理论上最多能处理几个点”。
