最可靠方式是使用 matchMedia("(pointer: coarse)")，它检测主指针精度而非硬件型号，触屏通常上报 coarse，且支持动态监听输入变化；ontouchstart 和 maxTouchPoints 均不可靠，已被弃用或易误判。
浏览器本身不提供直接判断“当前设备是否为触屏设备”的可靠 API，navigator.maxTouchPoints 已被废弃，matchMedia("(pointer: coarse)") 和 "ontouchstart" in window 各有局限——不能单靠一个条件下结论。
用 matchMedia("(pointer: coarse)") 判断输入精度类型
这是目前最符合规范、最稳定的方式，它检测的是用户代理报告的“主指针精度”，而非硬件型号。触屏设备通常上报 coarse（粗粒度），鼠标/触控板则多为 fine（细粒度）。
但注意：matchMedia 是响应式能力查询，不是一次性检测——它可能随用户切换输入方式（比如插上鼠标、外接触摸屏）而动态变化。
- 推荐写法：
const isCoarsePointer = window.matchMedia("(pointer: coarse)").matches; - 需监听变化时加
addEventListener("change", ...)，尤其在支持混合输入的设备（如二合一笔记本）上很重要 - 在 Safari 13.1+、Chrome 65+、Firefox 64+ 中行为一致；IE 不支持，需降级处理
为什么 "ontouchstart" in window 不可靠
这个判断只反映浏览器是否“注册了 touch 事件监听能力”，和实际是否有触屏无关。现代桌面 Chrome/Firefox 在启用开发者工具模拟移动设备时会注入 ontouchstart，即使你用的是鼠标；Edge/IE11 在某些触控非触屏本上也可能返回 true。
更麻烦的是：部分 Android WebView 或微信内置浏览器会暴露 ontouchstart，但实际 touch 事件无法正常触发（比如被 touch-action: none 阻断后）。
- 不要单独用它做功能开关，比如
if ("ontouchstart" in window) { initSwipeHandler(); }可能误启逻辑 - 可作为辅助信号，配合
matchMedia使用：“coarse pointer + ontouchstart 存在”比单用任一条件都更可信 - 注意：Vue/React 等框架中，若在服务端渲染（SSR）环境执行该判断，
window未定义，会报错
避免用 navigator.maxTouchPoints 或 navigator.msMaxTouchPoints
这两个属性曾用于 IE/旧 Edge 获取最大触点数，但已被所有现代浏览器废弃（Chrome 107+ 返回 0，Firefox 始终返回 0）。MDN 明确标注为“non-standard”且“deprecated”。
将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。
如果你在老项目里看到类似代码：
if (navigator.maxTouchPoints > 0 || navigator.msMaxTouchPoints > 0) { ... }
请直接删除或替换为 matchMedia 方案。它既不准确，也无法反映真实交互意图（比如 Surface 设备连着鼠标时，maxTouchPoints 仍是 >0，但用户此刻并不想用滑动操作）。
真实场景下的推荐组合判断
没有银弹。你要解决的问题决定了判断粒度：
- 只想优化滚动/滑动体验？优先用
matchMedia("(pointer: coarse)")，再监听change动态调整 - 要区分点击是 tap 还是 click，并绑定不同事件？别提前判断设备，改用事件委托监听
touchstart+click并加preventDefault()控制冒泡 - 需统计触屏用户占比？服务端 UA 解析（如
ua-parser-js）+ 客户端matchMedia双采样，比单端更准
真正容易被忽略的，是“触屏设备 ≠ 用户正在用触屏”——二合一设备、带触控屏的台式机、甚至某些车载浏览器，都可能在某次操作中切换输入模式。硬编码设备类型判断，不如让交互逻辑对输入方式保持弹性。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
