最稳妥的javascript检测逻辑是先用/android/i匹配安卓，再用/iphone|ipad|ipod/i且排除含android的ua双重确认ios；需规避ipados 13+ ua伪装、安卓webview伪造ipad等误判，并优先保障android误判为ios时的兼容性。
直接用 navigator.userAgent 配合正则判断，是最轻量、最通用的方案；但要注意 iOS 的误判风险——比如某些安卓浏览器会伪造含 iPad 的 UA 字符串。
怎么用 JavaScript 检测是 iOS 还是 Android
核心逻辑就是从 navigator.userAgent 里找关键词，但不能只看有没有 iPhone 或 Android：
-
/iPhone|iPad|iPod/i.test(navigator.userAgent)只能说明“可能是 iOS”，但部分安卓 WebView（如早期 QQ 浏览器）也会塞进iPad来兼容页面 - 更稳妥的做法是加一道排除：检查
!window.MSStream（IE/Edge 旧版有该属性，现代 iOS Safari 没有），或结合navigator.platform排除Win32/Linux平台 -
/Android/i.test(navigator.userAgent)相对可靠，但注意大小写不敏感匹配，避免漏掉小写的android
为什么 navigator.platform 不够用
navigator.platform 返回的是硬件平台标识，不是操作系统，容易混淆：
- iOS 设备返回
MacIntel（不是iOS），和 macOS 桌面版一样 - 部分安卓平板可能返回
Linux arm64，但有些定制 ROM 会返回Win32或空字符串 - 仅靠它无法区分 iOS 和 macOS，也不能识别 PWA 安装后运行在 iOS 上的 WebApp（仍显示
MacIntel）
常见误判场景和绕过方式
真实项目里踩过的坑比文档写的多：
- 微信内置浏览器在 iOS 上 UA 含
iPhone且无Android，但部分安卓版微信也会注入iPad字样 → 建议优先用/Android/i兜底，再用/iPhone|iPad|iPod/i+!/Android/i双重确认 - iPadOS 13+ 默认 UA 和 macOS Safari 一致（带
Macintosh），不再含iPad→ 必须配合maxTouchPoints > 1或matchMedia('(pointer: coarse)').matches辅助判断 - 某些企业内网浏览器会屏蔽 UA 或返回空字符串 → 加 fallback：默认走 Android 样式（因为 iOS 对 CSS/JS 兼容性要求更高，保守起见先适配更严格的平台）
要不要用第三方库
像 ua-parser-js 这类库封装了大量 UA 规则，但引入成本高、更新滞后：
- 它依赖维护者手动更新规则，新发布的 iOS 18 Beta 或鸿蒙 NEXT 的 UA 可能几周内不被识别
- 压缩后仍约 8KB，对首屏性能敏感的页面不划算
- 真要上库，建议只用它的解析器（
new UAParser().getOS()），别用它自动执行逻辑，自己控制 fallback 行为
实际部署时，最关键的不是“100% 准确”，而是“出错时行为可预期”——比如 iOS 误判成 Android，最多是滚动条样式不对；但 Android 误判成 iOS，可能导致调用不存在的 webkit-playsinline 属性或跳过必要 polyfill。所以检测逻辑里，宁可漏判，不要错判。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
