2025年前端做浏览器适配最容易踩的一块砖头就是版本检测。以前用navigator.userAgent一行正则就能判断 Safari、取出 iOS 版本号的日子已经彻底过去了。Chrome 从第 117 个大版本开始UA 字符串里的平台版本号被统一改成了 0.0.0而 Safari 这边动静虽然没那么猛但也开始逐步削减 UA 里的细节信息加上每年都要跟着 iOS 升一次大版本很多原本“写着玩玩”的检测代码现在是真的会误伤线上用户。这篇文章聊的是 2025 年在做 Safari 和 iOS 版本检测时的几条新思路。不是教你怎么再找一个能用的 UA 正则而是把“识别浏览器”这件事从版本号匹配迁移到能力检测和特征矩阵上顺便给出一份可以直接抄的检测模块以及这一年里我踩过的坑。适合正在维护 H5 页面、混合 App 壳、Web 桌面端适配的前端同学也适合准备做跨端兼容层的人参考。1. Safari 版本检测的老路为什么走不通1.1 UA 字符串曾经是唯一可靠的“身份证”很长时间里浏览器识别就是字符串匹配。移动端 H5 开发里判断是不是 iOS Safari 几乎全靠navigator.userAgent里的iPhone、CPU iPhone OS、Version/17.4这些字段。比如 iOS 17.4 上的真机 UA 大致长这样Mozilla/5.0 (iPhone; CPU iPhone OS 17_4 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.4 Mobile/15E148 Safari/604.1里面有iPhone直接告诉你设备类型iPhone OS 17_4告诉你系统版本Version/17.4还告诉你 Safari 版本605.1.15是 WebKit 版本号Mobile/15E148是构建号。这些字段凑在一起像一张写满信息的身份证前端拿着就能给用户“精准画像”。但问题也出在这里UA 字符串这三十多年积累下来的信息量对隐私来说是一种裸奔。浏览器厂商这些年一直在做减法只是 Safari 的进度一直没有 Chromium 那么激进。1.2 新版 UA 已经成为“不可靠数据源”Chromium 系浏览器的 UA 冻结是前端行业 2022 年就开始预告的事。到 2025 年绝大多数 Chromium 内核浏览器的 UA 字符串里操作系统版本号、设备型号、浏览器完整 build 号都已经变成了固定值比如桌面 Chrome 的 UA 结尾统一是Chrome/117.0.0.0 Safari/537.36。这种字符串已经没有任何“区分具体系统补丁版本”的能力。Safari 这边呢苹果虽然没有官方宣布冻结 UA但从近几个大版本的变更看趋势已经很明确新版 WebKit 在逐步减少构建号、设备型号、系统小版本号的暴露。某些隐私模式下UA 里甚至看不到Mobile/15E148这种构建标记只能拿到一个模糊的版本区间。到了 iOS 18、iOS 26 这一代单纯靠 UA 里的OS 18_4这样的字段做精确版本判断已经越来越不靠谱尤其不能用来判断小版本号。1.3 Safari 识别还有一个天然难点同名不同核Safari 的本质是“WebKit 内核 Apple 外壳”。但 iOS 上的第三方浏览器比如某国产浏览器、某国外浏览器在 iOS 上全部被强制使用 WKWebView也就是内核本来就是 WebKit。这些浏览器在 UA 里往往会伪装成 Safari甚至故意保留Version/17.4这种标记让服务器误以为它是“真 Safari”。这就是 Safari 检测最麻烦的地方你不是在区分“Safari”和“非Safari”而是在区分“Apple 官方外壳”和“WebKit 内核的第三方壳”。UA 字符串在这个维度上基本是失效的因为只要内核一样别人想伪装你你根本没有办法从 UA 里看出差别。明白了这个前提你就知道为什么 2025 年还能讲出“新思路”来我们要做的不是在 UA 文本里玩正则而是从浏览器暴露出来的“行为指纹”里找线索。2. 转向能力检测先认“能做什么”再猜“是什么”2.1 能力检测的核心思路能力检测的思想很简单不直接问“你是哪个浏览器”而是问“你支持不支持某个特性”。如果支持就走支持新特性的逻辑不支持就走降级逻辑。这种思路天然比版本号匹配抗造因为浏览器升级往往只会增加能力不会轻易移除能力。举个例子以前判断某个功能是否可用可能会写成“如果 iOS 版本 15则使用新特性”。能力检测的写法变成“如果window.someNewAPI存在则使用新特性”。后者的好处是你不关心对方是 iOS 15.1 还是 iOS 15.4也不关心 UA 是否伪造只要能力在就能用。但能力检测也不是万能的。有些场景确实需要知道“你是哪个浏览器”比如你要给 Safari 专门写一个 CSS 兼容补丁或者要绕过 WebKit 的某个 bug。这种时候纯能力检测帮不了你你必须结合多个特征做“特征矩阵”判断。2.2 一套实用的 Safari 特征矩阵结合 2025 年还在稳定的浏览器行为我整理了一套组合判断方案。单个特征都有被伪装的风险但多个特征组合起来可信度会高很多。先看几个关键特征navigator.vendorSafari 会返回字符串Apple Computer, Inc.其他大多数浏览器要么返回空字符串要么返回Google Inc.或Mozilla。这是个很老的属性但 Safari 一直没改。window.GestureEvent这是 iOS Safari 上独有的构造函数桌面 Safari 没有Chromium 系浏览器也没有。只要这个对象存在基本可以断定是 iOS 上的 WebKit 内核环境。CSS.supports((-webkit-touch-callout: none))这是 WebKit 私有属性检测能区分 WebKit 与 Blink/Gecko 的 CSS 能力差异但注意它无法区分“Safari 外壳”和“iOS 上的第三方 WKWebView 壳”。navigator.userAgentDataUA-CH APIChromium 系新浏览器都有Safari 完全没有实现。这个属性是“否定式特征”里的利器一旦不存在说明不是较新版 Chromium。把这些特征组合起来可以得到一个比 UA 正则可靠得多的判断逻辑。注意这些都是我在实际项目中验证过的组合不是网上抄来的“一行isSafari”。2.3 识别 iOS 与 iPadOS 的一个隐藏坑Safari 版本检测绕不开 iOS 和 iPadOS 的区分。iPadOS 13 之后iPad 上的 Safari 在“桌面网站”模式下UA 里的设备字段会变成Macintosh平台字段会变成MacIntel看起来和 Mac 上的一模一样。很多人这里就栽了。真正的区分点在两个地方触摸点和屏幕尺寸。iPad 无论怎么伪装成 Mac它仍然是一台触摸设备navigator.maxTouchPoints会返回大于 1 的值而 Mac 上接普通鼠标键盘时这个值通常为 0只有接了触摸屏才会大于 1。再加上视口宽度、window.innerWidth、媒体查询里的(hover: none) and (pointer: coarse)这些特征基本可以拼出完整的信息。我在实际项目里就是靠这套组合把 iPadOS 桌面模式识别出来的。但这里也要提醒一句用户如果在 iPad 上外接鼠标触摸点这个特征会变得模糊你只能靠“多特征投票”来兜底。3. iOS 版本推导的三条新路径前端经常遇到这种需求服务端下发了一个样式策略说“iOS 17 以下使用旧布局17 以上使用新布局”。以前直接截取 UA 里的 OS 字段就能判断现在 UA 里信息越来越少怎么推导 iOS 版本就成了 2025 年的新问题。下面三条路径从简单到复杂我都实测过。3.1 路径一用 Safari 主版本号反向对应 iOS 版本这条路径最简单但有个前提UA 里还能拿到 Safari 的Version/字段。苹果的产品节奏很规律每年新 iOS 大版本发布时都会同步更新 Safari 大版本号。也就是说iOS 18 对应 Safari 18iOS 19 对应 Safari 19iOS 26 对应 Safari 26。平时做前端根本不需要知道 iOS 的小版本号拿到 Safari 的主版本直接减一个偏移量就能大概对齐 iOS 主版本。const ua navigator.userAgent; const safariVersionMatch ua.match(/Version\/(\d)/); if (safariVersionMatch) { // iOS 主版本至少是 Safari 主版本对应的大版本 const safariMajor parseInt(safariVersionMatch[1], 10); // 苹果的大版本对应关系基本是 Safari N - iOS N console.log(iOS major version roughly:, safariMajor); }这条路径的坑是一旦苹果激进地把Version/从 UA 里移除或者第三方浏览器把这个字段伪装成别的值计算结果就会失准。所以它适合当“过渡方案”和“兜底方案”不适合当唯一依据。3.2 路径二媒体查询与设备特征硬推断如果 UA 已经拿不到版本号还有一条路用设备尺寸、视口参数、safe-area 等环境特征搭配已知设备型号反推 iOS 版本。这里的思路是分两步先识别出设备型号再根据设备支持的 iOS 版本范围做区间判断。比如 iPhone 16 Pro Max 的宽高在 CSSdevice-width下通常表现为 440 x 956 以内视口宽度在 430 左右。同一款 iPhone 能安装的 iOS 版本是有范围的比如首发预装 iOS 18最高能升级到 iOS 26那“iOS 版本至少是 18”这个下限就定了。const mql window.matchMedia((device-width: 430px) and (device-height: 932px)); if (mql.matches) { // 这是 iPhone Pro Max 系列的典型尺寸iOS 主版本下限基本能确定 }也可以结合viewport-fitcover和env(safe-area-inset-bottom)到底部指示条的距离判断是不是刘海屏再结合device-width区分是 iPhone 还是 iPad。这套方法适合做“粗粒度”的 iOS 版本区间判断精度到“iOS 大版本有没有超过某个阈值”这个级别再细就靠不住了。原因很简单同一款设备型号对应的 iOS 版本从来都是一个区间而不是一个精确值所以分辨率推断只能帮你压线不能帮你定位。3.3 路径三可验证的“能力阈值法”这条路径是 2025 年最值得推荐的。它的核心不是猜版本而是建立一张“iOS 大版本 → 新能力”的映射表用“某个 API 存不存在”来判定“版本是否 某个阈值”。举个例子假设你的业务需要一个必须 iOS 17 才稳定的能力async clipboard与其判断iOS 17不如直接探测navigator.clipboard window.ClipboardItem。如果存在说明版本大概率在 iOS 16 以上如果结合其他特性还能逐步逼近准确版本。function getIOSFeatureLevel() { const flags { // iOS 14.5 的典型能力 hasClipboardItem: typeof ClipboardItem ! undefined, // iOS 15 的典型能力 hasBroadcastChannel: BroadcastChannel in window, // iOS 16 的典型能力 hasContainerQueries: container-type in document.documentElement.style, // iOS 17 的典型能力 hasAsyncClipboardWrite: !!navigator.clipboard?.writeText, }; return flags; }这种方法的精髓在于你不是在告诉服务器“我是 iOS 17”而是在告诉服务器“我支持这些能力”。服务端看到的能力清单比一个孤零零的版本号更好用因为版本号只能做大小比较能力清单可以直接驱动功能开关。当然能力阈值法也有它的盲区某些能力是长期存在的不能被当成新版本标志某些能力在同一版本的不同设备上行为还不一样。所以使用前必须去真机上验证不能只看 MDN 的兼容性表。4. 一个可直接抄作业的检测模块说了这么多思路给出一份我在 2025 年还在用的检测模块。这个模块已经在一个混合 App 壳里跑了大半年线上的判断准确率能接受但我也要先声明它不可能 100% 准确尤其是在 iOS 第三方浏览器伪装 UA 的场景下谁都不敢打包票。它的价值是给你一个经过实践检验的起点。4.1 代码实现/** * 2025 Safari / iOS 版本检测模块 * 采用能力检测 特征矩阵逐步降级到 UA 解析 */ (function (global) { use strict; const ua navigator.userAgent || ; const platform (navigator.userAgentData?.platform || navigator.platform || ).toLowerCase(); const vendor (navigator.vendor || ).toLowerCase(); // 判断是否 WebKit 内核家族 const isWebKitFamily WebkitAppearance in document.documentElement.style || WebkitPerspective in document.documentElement.style; // 判断是否 Chromium 家族注意UA 里面有 Safari 字段不代表是 Safari const isChromiumFamily !!window.chrome !!navigator.userAgentData (navigator.userAgentData.brands || []).some(function (b) { return /chrom/i.test(b.brand); }); // 判断是否苹果环境 const isAppleEnv vendor.indexOf(apple) 0; // 判断触摸能力 const maxTouchPoints navigator.maxTouchPoints || 0; const result { // 是否为 WebKit 内核 isWebKit: isWebKitFamily, // 是否为 Safari 浏览器外壳尽力判断 isSafari: false, // 是否为 iOS / iPadOS 环境 isIOS: false, // 是否为 iPadOS 桌面模式 isIPadOSDesktop: false, // iOS 主版本号无法精确时返回 null iosMajor: null, // 设备平台原始值 platform: platform, }; // 判断 iOS 环境 const isIOSUA /iphone|ipad|ipod/i.test(ua); const isIPadLikeMac (platform macintosh || platform macintel) maxTouchPoints 1; if (isIOSUA || isIPadLikeMac) { result.isIOS true; } result.isIPadOSDesktop isIPadLikeMac; // 判断 Safari 外壳 // 前提必须是 WebKit 内核 苹果 vendor 非 Chromium if (isWebKitFamily isAppleEnv !isChromiumFamily) { result.isSafari true; } // 尝试从 UA 读取 iOS 版本号老方案仍有兜底价值 const osMatch ua.match(/OS (\d)_(\d)(?:_(\d))?/); if (osMatch) { result.iosMajor parseInt(osMatch[1], 10); } else if (result.isSafari) { // 尝试用 Safari 版本号估算 iOS 主版本 const verMatch ua.match(/Version\/(\d)/); if (verMatch) { const safariMajor parseInt(verMatch[1], 10); // iOS 大版本与 Safari 大版本基本对齐 result.iosMajor safariMajor; } } // 输出结果便于调试 if (global.console global.console.debug) { global.console.debug([detect], result); } global.__browserInfo result; })(window);这段代码的核心顺序是先用能力特征判断内核和外壳再降级到 UA 解析版本号。navigator.userAgentData是 2025 年识别 Chromium 家族的重要依据Safari 没有实现它所以只要这个对象存在且 brands 里有 Chromium 相关字样基本就能排除 Safari 嫌疑。4.2 参数与判定顺序的设计理由为什么先判断 WebKit再判断 Apple vendor最后才判断 Chromium因为伪装的方向主要是“非 Safari 伪装成 Safari”而不是反向伪装。Chromium 系的浏览器 UA 里虽然带着Safari字样但它们在navigator.vendor、window.GestureEvent、userAgentData这些特征上跟真 Safari 对不上。所以先把“铁证”找出来让伪装者暴露。从代码里也能看到我没有把window.GestureEvent作为必需品。原因是某些 iOS 16 以下的老版本设备上这个属性在部分 WKWebView 环境里存在但在某些 App 内置 webview 里又会被禁用。只把它当成加分项而不是决定性因素。判断 iPadOS 桌面模式时我用的组合是platform macintosh maxTouchPoints 1。这里有个细节navigator.platform在老版本 Safari 上经常会返回空字符串或者MacIntel所以我还兼容了userAgentData?.platform。如果你的项目目标系统比较老记得保留这段兼容逻辑。4.3 与功能开关、服务端下发的配合有了检测结果怎么把它用起来我建议把它跟业务解耦不要在业务代码里散布几十个if (__browserInfo.iosMajor 17)。推荐的做法是把检测结果统一丢到一个数据属性里比如在document.documentElement上挂>html[data-safaritrue] .some-component { /* Safari 专有适配 */ } html[data-ios-major16] .some-component { /* iOS 16 及以下的降级样式 */ }JS 业务侧则走“能力清单”而不是具体版本号。检测模块只负责把“我能干什么”传给后端后端根据能力清单下发策略。举个例子// 上报能力清单 fetch(/api/enter, { method: POST, body: JSON.stringify({ platform: __browserInfo.platform, isSafari: __browserInfo.isSafari, iosMajor: __browserInfo.iosMajor, features: { dialog: showModal in HTMLDialogElement.prototype, containerQuery: container-type in document.documentElement.style, asyncClipboard: !!navigator.clipboard?.writeText, }, }), });服务端拿到的已经不是一个干巴巴的版本号而是一份“可用能力清单”下发的降级策略自然更精准。4.4 快速验证清单检测模块写完之后先不要直接丢到线上我一般在本地搭一个快速验证页面把关键结果打印出来然后用下面的清单过一遍真 iPhone 最新 iOS Safari应该识别为isIOS: true, isSafari: true。真 iPhone 最新 Chrome AppiOS 上的 WKWebView应该识别为isIOS: true, isSafari: false。真 iPad 桌面模式 Safari应该识别为isIOS: true, isIPadOSDesktop: true, isSafari: true。Mac 桌面 Chrome应该识别为isIOS: false, isSafari: false。Mac 桌面 Safari应该识别为isIOS: false, isSafari: true。隐私模式的 iOS SafariisIOS: true版本号可能缺失但至少能识别平台。这套检测在以上场景下准确率足够支撑日常业务。遇到拿不准的情况就把navigator.userAgent、navigator.platform、navigator.vendor、navigator.maxTouchPoints四个原始值打印出来对照基准数据判断。5. 常见问题与排查技巧实录5.1 UA 里明明有 Safari但它不是 Safari这是 2025 年最容易把人绕晕的问题。Chromium 系浏览器为了兼容历史页面UA 字符串末尾一直带着Safari/537.36这种字样。如果你写的是/safari/i.test(ua)这种老判断那在所有 Chrome、Edge 里都会被误判成 Safari。解决办法就是上面代码里的“排除法”先看navigator.userAgentData是否存在存在则基本认定是新版 Chromium 家族再看navigator.vendorChromium 系通常不会返回 “Apple Computer, Inc.”。这两个特征合在一起可以过滤掉绝大多数伪装。5.2 桌面 Mac Safari 被误判成 iOS这个问题大多出在platform判断上。Mac 上navigator.platform返回MacIntel如果代码里把MacIntel也归入 iOS 判定条件就会误伤桌面 Safari。核心对策就是引入触摸点检测真 Mac 的maxTouchPoints通常是 0而 iPad 即使伪装成 Mac触摸点仍然大于 1。只有同时满足“MacIntel 触摸点大于 1”才可能是 iPadOS 桌面模式。5.3 隐私模式下特征发生变化iOS Safari 的隐私模式无痕模式会在某些维度上削弱浏览器特征。常见的变化包括 UA 里的构建号被移除localStorage写入抛异常indexedDB行为受限某些 API 返回空值。建议把检测逻辑做成“容错式”的不要因为某个 API 抛错就让整个模块崩溃。用try/catch包住所有可能报错的部分优先级是“平台判断 内核判断 版本判断”。隐私模式下版本信息拿不到很正常能识别平台和内核就已经满足了 90% 的业务需求。5.4 检测结果的验证方法这个模块跑一段时间后最有效的验证手段是埋点上报。在真实用户环境里把设备型号、系统版本、浏览器版本、检测结果一起上报然后用少量真实机做对照。不用多几十台真机跑一周你就能看到自己的准确率分布。如果发觉某个版本的误判率特别高就针对性把那个版本的原始特征加入矩阵重新调整判定顺序。这就是特征矩阵方案相比单一 UA 方案的优势它是活的可以持续迭代。5.5 一些补充的踩坑经验我再补几个细节都是代码注释里不太好写的navigator.platform在 iOS 16 之后的某些 WKWebView 里会返回空字符串导致平台判断失效。处理方式是把userAgentData?.platform优先级放在navigator.platform前面前者拿不到再降级。CSS.supports((-webkit-touch-callout: none))在 iOS 真机上返回 true在 Mac 桌面 Safari 上返回 false但这不是一个稳定的跨版本特征尽量只用作辅助。永远不要依赖navigator.standalone来判断 iOS 版本它只表示“是否以主屏幕 Web App 模式运行”跟版本号没有任何关系。检测代码的放置位置最好在head里越早执行越好。如果放在页面底部一旦某些业务组件已经根据错误的浏览器判断完成了初始化再修正就晚了。我个人实际操作中的体会是版本检测这件事越往后越不是“找一个正则搞定一切”而是一个持续迭代的特征工程。与其追求把 iOS 版本精确到小数不如把业务需求翻译成“能力需求”让浏览器告诉你它能做什么你再决定降不降级。这套思路就算两年后再看也仍然适用。最后再分享一个小技巧在桌面 Safari 的开发者工具里可以手动修改 User Agent 字符串来模拟各种 iOS 环境但真实设备的特征缺口是模拟工具永远补不上的重要功能上线前务必留一次真机回归。
2025年前端做浏览器适配最容易踩的一块砖头就是版本检测。以前用navigator.userAgent一行正则就能判断 Safari、取出 iOS 版本号的日子已经彻底过去了。Chrome 从第 117 个大版本开始UA 字符串里的平台版本号被统一改成了 0.0.0而 Safari 这边动静虽然没那么猛但也开始逐步削减 UA 里的细节信息加上每年都要跟着 iOS 升一次大版本很多原本“写着玩玩”的检测代码现在是真的会误伤线上用户。这篇文章聊的是 2025 年在做 Safari 和 iOS 版本检测时的几条新思路。不是教你怎么再找一个能用的 UA 正则而是把“识别浏览器”这件事从版本号匹配迁移到能力检测和特征矩阵上顺便给出一份可以直接抄的检测模块以及这一年里我踩过的坑。适合正在维护 H5 页面、混合 App 壳、Web 桌面端适配的前端同学也适合准备做跨端兼容层的人参考。1. Safari 版本检测的老路为什么走不通1.1 UA 字符串曾经是唯一可靠的“身份证”很长时间里浏览器识别就是字符串匹配。移动端 H5 开发里判断是不是 iOS Safari 几乎全靠navigator.userAgent里的iPhone、CPU iPhone OS、Version/17.4这些字段。比如 iOS 17.4 上的真机 UA 大致长这样Mozilla/5.0 (iPhone; CPU iPhone OS 17_4 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.4 Mobile/15E148 Safari/604.1里面有iPhone直接告诉你设备类型iPhone OS 17_4告诉你系统版本Version/17.4还告诉你 Safari 版本605.1.15是 WebKit 版本号Mobile/15E148是构建号。这些字段凑在一起像一张写满信息的身份证前端拿着就能给用户“精准画像”。但问题也出在这里UA 字符串这三十多年积累下来的信息量对隐私来说是一种裸奔。浏览器厂商这些年一直在做减法只是 Safari 的进度一直没有 Chromium 那么激进。1.2 新版 UA 已经成为“不可靠数据源”Chromium 系浏览器的 UA 冻结是前端行业 2022 年就开始预告的事。到 2025 年绝大多数 Chromium 内核浏览器的 UA 字符串里操作系统版本号、设备型号、浏览器完整 build 号都已经变成了固定值比如桌面 Chrome 的 UA 结尾统一是Chrome/117.0.0.0 Safari/537.36。这种字符串已经没有任何“区分具体系统补丁版本”的能力。Safari 这边呢苹果虽然没有官方宣布冻结 UA但从近几个大版本的变更看趋势已经很明确新版 WebKit 在逐步减少构建号、设备型号、系统小版本号的暴露。某些隐私模式下UA 里甚至看不到Mobile/15E148这种构建标记只能拿到一个模糊的版本区间。到了 iOS 18、iOS 26 这一代单纯靠 UA 里的OS 18_4这样的字段做精确版本判断已经越来越不靠谱尤其不能用来判断小版本号。1.3 Safari 识别还有一个天然难点同名不同核Safari 的本质是“WebKit 内核 Apple 外壳”。但 iOS 上的第三方浏览器比如某国产浏览器、某国外浏览器在 iOS 上全部被强制使用 WKWebView也就是内核本来就是 WebKit。这些浏览器在 UA 里往往会伪装成 Safari甚至故意保留Version/17.4这种标记让服务器误以为它是“真 Safari”。这就是 Safari 检测最麻烦的地方你不是在区分“Safari”和“非Safari”而是在区分“Apple 官方外壳”和“WebKit 内核的第三方壳”。UA 字符串在这个维度上基本是失效的因为只要内核一样别人想伪装你你根本没有办法从 UA 里看出差别。明白了这个前提你就知道为什么 2025 年还能讲出“新思路”来我们要做的不是在 UA 文本里玩正则而是从浏览器暴露出来的“行为指纹”里找线索。2. 转向能力检测先认“能做什么”再猜“是什么”2.1 能力检测的核心思路能力检测的思想很简单不直接问“你是哪个浏览器”而是问“你支持不支持某个特性”。如果支持就走支持新特性的逻辑不支持就走降级逻辑。这种思路天然比版本号匹配抗造因为浏览器升级往往只会增加能力不会轻易移除能力。举个例子以前判断某个功能是否可用可能会写成“如果 iOS 版本 15则使用新特性”。能力检测的写法变成“如果window.someNewAPI存在则使用新特性”。后者的好处是你不关心对方是 iOS 15.1 还是 iOS 15.4也不关心 UA 是否伪造只要能力在就能用。但能力检测也不是万能的。有些场景确实需要知道“你是哪个浏览器”比如你要给 Safari 专门写一个 CSS 兼容补丁或者要绕过 WebKit 的某个 bug。这种时候纯能力检测帮不了你你必须结合多个特征做“特征矩阵”判断。2.2 一套实用的 Safari 特征矩阵结合 2025 年还在稳定的浏览器行为我整理了一套组合判断方案。单个特征都有被伪装的风险但多个特征组合起来可信度会高很多。先看几个关键特征navigator.vendorSafari 会返回字符串Apple Computer, Inc.其他大多数浏览器要么返回空字符串要么返回Google Inc.或Mozilla。这是个很老的属性但 Safari 一直没改。window.GestureEvent这是 iOS Safari 上独有的构造函数桌面 Safari 没有Chromium 系浏览器也没有。只要这个对象存在基本可以断定是 iOS 上的 WebKit 内核环境。CSS.supports((-webkit-touch-callout: none))这是 WebKit 私有属性检测能区分 WebKit 与 Blink/Gecko 的 CSS 能力差异但注意它无法区分“Safari 外壳”和“iOS 上的第三方 WKWebView 壳”。navigator.userAgentDataUA-CH APIChromium 系新浏览器都有Safari 完全没有实现。这个属性是“否定式特征”里的利器一旦不存在说明不是较新版 Chromium。把这些特征组合起来可以得到一个比 UA 正则可靠得多的判断逻辑。注意这些都是我在实际项目中验证过的组合不是网上抄来的“一行isSafari”。2.3 识别 iOS 与 iPadOS 的一个隐藏坑Safari 版本检测绕不开 iOS 和 iPadOS 的区分。iPadOS 13 之后iPad 上的 Safari 在“桌面网站”模式下UA 里的设备字段会变成Macintosh平台字段会变成MacIntel看起来和 Mac 上的一模一样。很多人这里就栽了。真正的区分点在两个地方触摸点和屏幕尺寸。iPad 无论怎么伪装成 Mac它仍然是一台触摸设备navigator.maxTouchPoints会返回大于 1 的值而 Mac 上接普通鼠标键盘时这个值通常为 0只有接了触摸屏才会大于 1。再加上视口宽度、window.innerWidth、媒体查询里的(hover: none) and (pointer: coarse)这些特征基本可以拼出完整的信息。我在实际项目里就是靠这套组合把 iPadOS 桌面模式识别出来的。但这里也要提醒一句用户如果在 iPad 上外接鼠标触摸点这个特征会变得模糊你只能靠“多特征投票”来兜底。3. iOS 版本推导的三条新路径前端经常遇到这种需求服务端下发了一个样式策略说“iOS 17 以下使用旧布局17 以上使用新布局”。以前直接截取 UA 里的 OS 字段就能判断现在 UA 里信息越来越少怎么推导 iOS 版本就成了 2025 年的新问题。下面三条路径从简单到复杂我都实测过。3.1 路径一用 Safari 主版本号反向对应 iOS 版本这条路径最简单但有个前提UA 里还能拿到 Safari 的Version/字段。苹果的产品节奏很规律每年新 iOS 大版本发布时都会同步更新 Safari 大版本号。也就是说iOS 18 对应 Safari 18iOS 19 对应 Safari 19iOS 26 对应 Safari 26。平时做前端根本不需要知道 iOS 的小版本号拿到 Safari 的主版本直接减一个偏移量就能大概对齐 iOS 主版本。const ua navigator.userAgent; const safariVersionMatch ua.match(/Version\/(\d)/); if (safariVersionMatch) { // iOS 主版本至少是 Safari 主版本对应的大版本 const safariMajor parseInt(safariVersionMatch[1], 10); // 苹果的大版本对应关系基本是 Safari N - iOS N console.log(iOS major version roughly:, safariMajor); }这条路径的坑是一旦苹果激进地把Version/从 UA 里移除或者第三方浏览器把这个字段伪装成别的值计算结果就会失准。所以它适合当“过渡方案”和“兜底方案”不适合当唯一依据。3.2 路径二媒体查询与设备特征硬推断如果 UA 已经拿不到版本号还有一条路用设备尺寸、视口参数、safe-area 等环境特征搭配已知设备型号反推 iOS 版本。这里的思路是分两步先识别出设备型号再根据设备支持的 iOS 版本范围做区间判断。比如 iPhone 16 Pro Max 的宽高在 CSSdevice-width下通常表现为 440 x 956 以内视口宽度在 430 左右。同一款 iPhone 能安装的 iOS 版本是有范围的比如首发预装 iOS 18最高能升级到 iOS 26那“iOS 版本至少是 18”这个下限就定了。const mql window.matchMedia((device-width: 430px) and (device-height: 932px)); if (mql.matches) { // 这是 iPhone Pro Max 系列的典型尺寸iOS 主版本下限基本能确定 }也可以结合viewport-fitcover和env(safe-area-inset-bottom)到底部指示条的距离判断是不是刘海屏再结合device-width区分是 iPhone 还是 iPad。这套方法适合做“粗粒度”的 iOS 版本区间判断精度到“iOS 大版本有没有超过某个阈值”这个级别再细就靠不住了。原因很简单同一款设备型号对应的 iOS 版本从来都是一个区间而不是一个精确值所以分辨率推断只能帮你压线不能帮你定位。3.3 路径三可验证的“能力阈值法”这条路径是 2025 年最值得推荐的。它的核心不是猜版本而是建立一张“iOS 大版本 → 新能力”的映射表用“某个 API 存不存在”来判定“版本是否 某个阈值”。举个例子假设你的业务需要一个必须 iOS 17 才稳定的能力async clipboard与其判断iOS 17不如直接探测navigator.clipboard window.ClipboardItem。如果存在说明版本大概率在 iOS 16 以上如果结合其他特性还能逐步逼近准确版本。function getIOSFeatureLevel() { const flags { // iOS 14.5 的典型能力 hasClipboardItem: typeof ClipboardItem ! undefined, // iOS 15 的典型能力 hasBroadcastChannel: BroadcastChannel in window, // iOS 16 的典型能力 hasContainerQueries: container-type in document.documentElement.style, // iOS 17 的典型能力 hasAsyncClipboardWrite: !!navigator.clipboard?.writeText, }; return flags; }这种方法的精髓在于你不是在告诉服务器“我是 iOS 17”而是在告诉服务器“我支持这些能力”。服务端看到的能力清单比一个孤零零的版本号更好用因为版本号只能做大小比较能力清单可以直接驱动功能开关。当然能力阈值法也有它的盲区某些能力是长期存在的不能被当成新版本标志某些能力在同一版本的不同设备上行为还不一样。所以使用前必须去真机上验证不能只看 MDN 的兼容性表。4. 一个可直接抄作业的检测模块说了这么多思路给出一份我在 2025 年还在用的检测模块。这个模块已经在一个混合 App 壳里跑了大半年线上的判断准确率能接受但我也要先声明它不可能 100% 准确尤其是在 iOS 第三方浏览器伪装 UA 的场景下谁都不敢打包票。它的价值是给你一个经过实践检验的起点。4.1 代码实现/** * 2025 Safari / iOS 版本检测模块 * 采用能力检测 特征矩阵逐步降级到 UA 解析 */ (function (global) { use strict; const ua navigator.userAgent || ; const platform (navigator.userAgentData?.platform || navigator.platform || ).toLowerCase(); const vendor (navigator.vendor || ).toLowerCase(); // 判断是否 WebKit 内核家族 const isWebKitFamily WebkitAppearance in document.documentElement.style || WebkitPerspective in document.documentElement.style; // 判断是否 Chromium 家族注意UA 里面有 Safari 字段不代表是 Safari const isChromiumFamily !!window.chrome !!navigator.userAgentData (navigator.userAgentData.brands || []).some(function (b) { return /chrom/i.test(b.brand); }); // 判断是否苹果环境 const isAppleEnv vendor.indexOf(apple) 0; // 判断触摸能力 const maxTouchPoints navigator.maxTouchPoints || 0; const result { // 是否为 WebKit 内核 isWebKit: isWebKitFamily, // 是否为 Safari 浏览器外壳尽力判断 isSafari: false, // 是否为 iOS / iPadOS 环境 isIOS: false, // 是否为 iPadOS 桌面模式 isIPadOSDesktop: false, // iOS 主版本号无法精确时返回 null iosMajor: null, // 设备平台原始值 platform: platform, }; // 判断 iOS 环境 const isIOSUA /iphone|ipad|ipod/i.test(ua); const isIPadLikeMac (platform macintosh || platform macintel) maxTouchPoints 1; if (isIOSUA || isIPadLikeMac) { result.isIOS true; } result.isIPadOSDesktop isIPadLikeMac; // 判断 Safari 外壳 // 前提必须是 WebKit 内核 苹果 vendor 非 Chromium if (isWebKitFamily isAppleEnv !isChromiumFamily) { result.isSafari true; } // 尝试从 UA 读取 iOS 版本号老方案仍有兜底价值 const osMatch ua.match(/OS (\d)_(\d)(?:_(\d))?/); if (osMatch) { result.iosMajor parseInt(osMatch[1], 10); } else if (result.isSafari) { // 尝试用 Safari 版本号估算 iOS 主版本 const verMatch ua.match(/Version\/(\d)/); if (verMatch) { const safariMajor parseInt(verMatch[1], 10); // iOS 大版本与 Safari 大版本基本对齐 result.iosMajor safariMajor; } } // 输出结果便于调试 if (global.console global.console.debug) { global.console.debug([detect], result); } global.__browserInfo result; })(window);这段代码的核心顺序是先用能力特征判断内核和外壳再降级到 UA 解析版本号。navigator.userAgentData是 2025 年识别 Chromium 家族的重要依据Safari 没有实现它所以只要这个对象存在且 brands 里有 Chromium 相关字样基本就能排除 Safari 嫌疑。4.2 参数与判定顺序的设计理由为什么先判断 WebKit再判断 Apple vendor最后才判断 Chromium因为伪装的方向主要是“非 Safari 伪装成 Safari”而不是反向伪装。Chromium 系的浏览器 UA 里虽然带着Safari字样但它们在navigator.vendor、window.GestureEvent、userAgentData这些特征上跟真 Safari 对不上。所以先把“铁证”找出来让伪装者暴露。从代码里也能看到我没有把window.GestureEvent作为必需品。原因是某些 iOS 16 以下的老版本设备上这个属性在部分 WKWebView 环境里存在但在某些 App 内置 webview 里又会被禁用。只把它当成加分项而不是决定性因素。判断 iPadOS 桌面模式时我用的组合是platform macintosh maxTouchPoints 1。这里有个细节navigator.platform在老版本 Safari 上经常会返回空字符串或者MacIntel所以我还兼容了userAgentData?.platform。如果你的项目目标系统比较老记得保留这段兼容逻辑。4.3 与功能开关、服务端下发的配合有了检测结果怎么把它用起来我建议把它跟业务解耦不要在业务代码里散布几十个if (__browserInfo.iosMajor 17)。推荐的做法是把检测结果统一丢到一个数据属性里比如在document.documentElement上挂>html[data-safaritrue] .some-component { /* Safari 专有适配 */ } html[data-ios-major16] .some-component { /* iOS 16 及以下的降级样式 */ }JS 业务侧则走“能力清单”而不是具体版本号。检测模块只负责把“我能干什么”传给后端后端根据能力清单下发策略。举个例子// 上报能力清单 fetch(/api/enter, { method: POST, body: JSON.stringify({ platform: __browserInfo.platform, isSafari: __browserInfo.isSafari, iosMajor: __browserInfo.iosMajor, features: { dialog: showModal in HTMLDialogElement.prototype, containerQuery: container-type in document.documentElement.style, asyncClipboard: !!navigator.clipboard?.writeText, }, }), });服务端拿到的已经不是一个干巴巴的版本号而是一份“可用能力清单”下发的降级策略自然更精准。4.4 快速验证清单检测模块写完之后先不要直接丢到线上我一般在本地搭一个快速验证页面把关键结果打印出来然后用下面的清单过一遍真 iPhone 最新 iOS Safari应该识别为isIOS: true, isSafari: true。真 iPhone 最新 Chrome AppiOS 上的 WKWebView应该识别为isIOS: true, isSafari: false。真 iPad 桌面模式 Safari应该识别为isIOS: true, isIPadOSDesktop: true, isSafari: true。Mac 桌面 Chrome应该识别为isIOS: false, isSafari: false。Mac 桌面 Safari应该识别为isIOS: false, isSafari: true。隐私模式的 iOS SafariisIOS: true版本号可能缺失但至少能识别平台。这套检测在以上场景下准确率足够支撑日常业务。遇到拿不准的情况就把navigator.userAgent、navigator.platform、navigator.vendor、navigator.maxTouchPoints四个原始值打印出来对照基准数据判断。5. 常见问题与排查技巧实录5.1 UA 里明明有 Safari但它不是 Safari这是 2025 年最容易把人绕晕的问题。Chromium 系浏览器为了兼容历史页面UA 字符串末尾一直带着Safari/537.36这种字样。如果你写的是/safari/i.test(ua)这种老判断那在所有 Chrome、Edge 里都会被误判成 Safari。解决办法就是上面代码里的“排除法”先看navigator.userAgentData是否存在存在则基本认定是新版 Chromium 家族再看navigator.vendorChromium 系通常不会返回 “Apple Computer, Inc.”。这两个特征合在一起可以过滤掉绝大多数伪装。5.2 桌面 Mac Safari 被误判成 iOS这个问题大多出在platform判断上。Mac 上navigator.platform返回MacIntel如果代码里把MacIntel也归入 iOS 判定条件就会误伤桌面 Safari。核心对策就是引入触摸点检测真 Mac 的maxTouchPoints通常是 0而 iPad 即使伪装成 Mac触摸点仍然大于 1。只有同时满足“MacIntel 触摸点大于 1”才可能是 iPadOS 桌面模式。5.3 隐私模式下特征发生变化iOS Safari 的隐私模式无痕模式会在某些维度上削弱浏览器特征。常见的变化包括 UA 里的构建号被移除localStorage写入抛异常indexedDB行为受限某些 API 返回空值。建议把检测逻辑做成“容错式”的不要因为某个 API 抛错就让整个模块崩溃。用try/catch包住所有可能报错的部分优先级是“平台判断 内核判断 版本判断”。隐私模式下版本信息拿不到很正常能识别平台和内核就已经满足了 90% 的业务需求。5.4 检测结果的验证方法这个模块跑一段时间后最有效的验证手段是埋点上报。在真实用户环境里把设备型号、系统版本、浏览器版本、检测结果一起上报然后用少量真实机做对照。不用多几十台真机跑一周你就能看到自己的准确率分布。如果发觉某个版本的误判率特别高就针对性把那个版本的原始特征加入矩阵重新调整判定顺序。这就是特征矩阵方案相比单一 UA 方案的优势它是活的可以持续迭代。5.5 一些补充的踩坑经验我再补几个细节都是代码注释里不太好写的navigator.platform在 iOS 16 之后的某些 WKWebView 里会返回空字符串导致平台判断失效。处理方式是把userAgentData?.platform优先级放在navigator.platform前面前者拿不到再降级。CSS.supports((-webkit-touch-callout: none))在 iOS 真机上返回 true在 Mac 桌面 Safari 上返回 false但这不是一个稳定的跨版本特征尽量只用作辅助。永远不要依赖navigator.standalone来判断 iOS 版本它只表示“是否以主屏幕 Web App 模式运行”跟版本号没有任何关系。检测代码的放置位置最好在head里越早执行越好。如果放在页面底部一旦某些业务组件已经根据错误的浏览器判断完成了初始化再修正就晚了。我个人实际操作中的体会是版本检测这件事越往后越不是“找一个正则搞定一切”而是一个持续迭代的特征工程。与其追求把 iOS 版本精确到小数不如把业务需求翻译成“能力需求”让浏览器告诉你它能做什么你再决定降不降级。这套思路就算两年后再看也仍然适用。最后再分享一个小技巧在桌面 Safari 的开发者工具里可以手动修改 User Agent 字符串来模拟各种 iOS 环境但真实设备的特征缺口是模拟工具永远补不上的重要功能上线前务必留一次真机回归。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
