最直接方式是用 $_SERVER['HTTP_USER_AGENT'] 获取原始UA字符串，但需先校验 isset() && !empty()，因其不可靠且可能为空；仅用于体验优化，不可用于安全逻辑；移动端应组合匹配设备关键词而非单看Mobile。
用 $_SERVER['HTTP_USER_AGENT'] 拿原始 UA 字符串最直接
PHP 本身不内置解析浏览器信息的函数，所有判断都基于 $_SERVER['HTTP_USER_AGENT'] 这个字符串。它由客户端（浏览器）主动发送，内容不可靠但唯一可用。注意：该值可能为空（比如某些爬虫、curl 未设 header），访问前必须判断是否存在且非空。
常见错误现象：Undefined index: HTTP_USER_AGENT —— 没加 isset() 就直接读取；或返回空字符串却当成有效 UA 处理。
- 始终用
isset($_SERVER['HTTP_USER_AGENT']) && !empty($_SERVER['HTTP_USER_AGENT'])做前置校验 - 不要信任 UA 内容，仅用于前端体验优化（如提示“请用 Chrome 打开”），不可用于权限或安全逻辑
- 移动端适配时，
Mobile和Android同时出现比单看Mobile更可靠
用 get_browser() 需提前配置 browscap.ini
get_browser() 是 PHP 内置函数，能返回解析后的数组（含 browser、version、ismobile 等字段），但它不是开箱即用的——必须在 php.ini 中启用并指向有效的 browscap.ini 文件路径。
典型坑点：本地开发环境启用了 get_browser()，但生产服务器没配 browscap，结果返回 false 或空数组，且无任何报错提示。
立即学习“PHP免费学习笔记（深入）”；
- 检查是否启用：
var_dump(ini_get('browscap'))，返回空说明未配置 - 推荐用 Composer 包
sinergi/browser-detector替代，无需 ini 配置，纯 PHP 实现 -
get_browser()性能较差，每次调用都会解析 ini 文件，高并发下建议缓存结果
正则匹配常见浏览器比依赖第三方更轻量
如果只需识别 Chrome/Firefox/Safari/Edge/WeChat/QQ 浏览器等主流类型，手动写几条 preg_match() 规则反而更快、更可控，也避免引入额外依赖。
注意 UA 字符串顺序和关键词重叠问题：比如 Edg 在新版 Edge 中出现，但旧版 IE 的 UA 里也有 Trident；微信内置浏览器 UA 同时含 MicroMessenger 和 QQBrowser，应优先匹配更具体的标识。
- Chrome：
/Chrome\/([0-9.]+)/i，但需排除Edg和OPR（Opera）干扰 - 微信：
/MicroMessenger\/([\d.]+)/i，放在 Safari / QQBrowser 判断之前 - iOS Safari：
/iPhone.*Safari|iPad.*Safari/i，不能只靠Safari，因为微信、QQ 也会带上
移动端检测不能只看 Mobile 字样
很多开发者以为 UA 含 Mobile 就是手机，但 iPad 的 UA 通常不含 Mobile，而部分桌面版 Chrome 开启设备模拟时又会强行加上。真正可靠的组合判断是：/(iPhone|iPad|iPod|Android|BlackBerry|IEMobile|Windows Phone)/i。
更麻烦的是，iOS 13+ 的 Safari UA 默认隐藏了 iPhone，只显示 Macintosh + ，但加了 Mobile —— 所以单独用 Mobile 仍有必要，只是不能作为唯一依据。
- 优先匹配具体设备关键词（
iPhone、Android），再 fallback 到Mobile+!Desktop - 别用
is_mobile这类模糊字段做响应式断点，CSS 媒体查询或 JSwindow.innerWidth更准确 - 微信、QQ、抖音内嵌浏览器本质是 WebView，UA 里既像 Safari 又像 Android，需单独识别
UA 解析永远是概率游戏，没有 100% 准确的方案。重点不是“识别对”，而是“识别错时别崩”——所有分支都要有默认 fallback，所有正则都要加 i 修饰符，所有字符串操作前都要做非空判断。真实项目里，往往一个 strpos() 查关键词就足够，过度设计解析逻辑反而增加维护成本。
