index.html判断手机端与PC端的方法

判断用户是手机端还是PC端，这在前端开发里是个老生常谈但又绕不开的问题。方法看似很多，但每种都有它的“坑”。今天，我们就来聊聊几种主流方案的原理、适用场景和那些需要特别注意的细节。

用 na vigator.userAgent 做最简判断

最直接、兼容性最好的方法，莫过于读取浏览器提供的 na vigator.userAgent 字符串。这个字符串包含了浏览器、操作系统、设备类型等信息，通过检查其中是否包含特定的关键词，就能快速判断。

不过，这里有几个常见的误区。比如，你不能简单地只搜索“Mobile”，因为有些iPad的UA里就没有这个词。反过来，只搜“iPad”也不行，因为从iOS 13开始，iPad在桌面模式下会主动隐藏“iPad”标识，伪装成Mac的Safari。

所以，一个相对稳妥的正则表达式是这样的：

• /Mobi|Android|iPhone|iPod|Opera Mini|IEMobile/i.test(na vigator.userAgent) —— 这个组合能覆盖市面上绝大多数的手机浏览器。
• 如果需要特别区分出iPad，可以补充一个条件：|| /iPad/i.test(na vigator.userAgent) && !/Macintosh.*Safari/i.test(na vigator.userAgent)。后半部分就是为了排除掉那些伪装成桌面Safari的iPad，避免误判。

另外，尽量别用 indexOf(“Android”) !== -1 这种写法，它对大小写敏感，不够安全。正则表达式加上 /i 标志（忽略大小写）才是更稳妥的选择。

用 matchMedia 判断视口宽度更可靠

UA检测有个天生的弱点：它可以被用户或浏览器伪造。相比之下，基于CSS媒体查询的 window.matchMedia 方法，判断的是当前视口的真实渲染宽度，更适合用来做响应式降级或功能开关。

举个例子，你可以在PC端强制加载一个更复杂的桌面版地图组件，而在移动端使用简化版。这里的关键在于，matchMedia 检测的是“视口宽度”，而不是“屏幕物理尺寸”。它会受到浏览器缩放、开发者工具模拟以及设备横竖屏切换的影响。

常用的判断阈值是768px：

• matchMedia(“(max-width: 768px)”).matches

但这个阈值并非金科玉律。比如，一些折叠屏手机展开后，视口宽度可能也小于768px，但它本质上可能更接近平板或PC的使用体验。因此，更精准的做法是组合判断：

• matchMedia(“(max-width: 768px)”).matches && na vigator.maxTouchPoints > 1

这样既考虑了视口尺寸，又兼顾了设备的触控能力。如果需要监听视口变化，记得使用 mediaQuery.addListener(handler)，对于旧版本的Safari，可能需要用 addRule 来做兼容处理。

服务端 UA 检测比前端更早，但有局限

如果你的页面是后端渲染的（比如用PHP、Node.js或通过Nginx配置），那么完全可以在服务器端就完成判断。通过解析HTTP请求头中的 User-Agent 字段，直接输出不同的HTML结构或body class。这样做的好处是首屏无需等待Ja vaScript执行，适配立即可见。

但服务端检测也有麻烦事：CDN可能会缓存不同设备的页面版本；各种爬虫的UA千奇百怪；国内微信、QQ内置浏览器的UA标识更是混乱不堪，很容易导致误判。

技术上倒不难实现：

• Nginx配置示例：if ($http_user_agent ~* “(Mobi|Android|iPhone)”) { set $is_mobile “1”; }，然后结合 try_files 指令进行页面分流。
• PHP等语言建议使用成熟的检测库（如 sinergi/browser-detector），自己写正则很容易漏掉Edge Mobile、三星浏览器这些变体。

当然，如果你的站点托管在GitHub Pages、Vercel这类纯静态服务上，那就无法进行服务端判断，只能依靠前端方案。

别忽略微信和 QQ 内置浏览器的特殊行为

国内开发尤其要注意微信和QQ的内置浏览器。它们的UA里通常同时包含“MicroMessenger”和“Mobile”，但有些安卓微信版本会将自己的UA伪装成桌面版Chrome，这会导致前端基于UA的判断完全失效。

这时候，matchMedia 结合 ‘ontouchstart’ in window（检测是否支持触摸事件）会更靠谱。但也要小心，在Chrome桌面版开启开发者工具模拟移动设备时，ontouchstart 也会被模拟出来。

可以采用的策略包括：

• 简单兜底：!!na vigator.userAgent.match(/MicroMessenger/i) || !!na vigator.userAgent.match(/QQ\/\d+/i)，先识别出是微信或QQ环境。
• 真机检测加强版：screen.width < 900 && ‘ontouchstart’ in window，结合屏幕宽度和触摸支持，排除掉桌面模拟的场景。
• 注意：微信JS-SDK里的 getNetworkType API是用来获取网络类型的（如4g、wifi），不能用于设备判断。

话说回来，在实际项目中，大多数场景下使用 na vigator.userAgent 结合 matchMedia 做双保险就已经足够了。真正棘手的是那些UA被刻意抹除或篡改的环境，比如某些定制版的企业微信，或者鸿蒙WebView的早期版本。遇到这种极端情况，最实在的兜底方案，可能就是提供一个让用户手动切换的按钮了。