特性检测 vs 浏览器检测：前端兼容性的火眼金睛与刻舟求剑

做前端兼容性开发这些年，我最大的一个领悟是：特性检测和浏览器检测，一个是火眼金睛，一个是刻舟求剑。火眼金睛是问“你具备这个能力吗”，浏览器检测是问“你是谁”，然后根据“你是谁”去推测你有没有能力。前者能看见真实世界，后者只看得见自己在船上刻下的那道痕迹——船已经走远了，痕迹还在原地。

我有过一次刻骨铭心的翻车。当时做一个支付页面，iPhone上点击支付按钮没有反应，Android一切正常。排查时第一时间看了User-Agent，发现系统版本是iOS 13.4.1，于是写了个判断：“非Safari 14以上版本就降级到旧支付流程”。上线当天iOS 14.x的用户全炸了——新版系统的UA字符串格式根本不是我判断的那个样子。折腾一晚上，最后发现真正原因根本不是浏览器版本，而是那个版本里WebView对pointer事件的处理方式变了。从那以后我彻底明白：用浏览器身份去推断能力，就像按图索骥却拿错了图。

这篇文章想把这套思路完整拆开，讲清楚特性检测与浏览器检测各自的价值、局限和正确用法。不管你是刚入行的前端，还是做跨端兼容的老手，希望这篇经验总结能帮你少走几次弯路。

1. 浏览器检测为什么是“刻舟求剑”：那些年我们被User-Agent坑惨的瞬间

1.1 一个支付页面的翻车复盘

先把我那个支付页面的问题说完整。

当时拿到Bug单，说iPhone上支付按钮点击无效，页面不跳转。我第一反应是去查Safari的版本兼容性。在开发者工具里模拟了一台iPhone，看到UA里的Safari版本是13.4，于是认为所有iOS 13的用户都会走问题分支。代码逻辑是这样的：

js复制const ua = navigator.userAgent;
const isOldSafari = ua.includes('iPhone') && /OS 13_4/.test(ua);
if (isOldSafari) {
  fallbackToLegacyPayment();
} else {
  runNewPayment();
}

看着挺合理对吧？问题恰恰出在这里。iOS 14的UA里，系统版本字段变成了OS 14_0，和13_4完全对不上，所以那些用户全都走了runNewPayment()的新流程。但真正的Bug是WebView里pointerup事件没触发，新版支付流程依赖这个事件，结果在iOS 14上直接就挂了。

后来改成特性检测，先判断环境是否支持Pointer Events：

js复制const hasPointerEvents = 'PointerEvent' in window;
const paymentFlow = hasPointerEvents ? 'standard' : 'legacy';

一秒定位，两行解决。那次之后我意识到，我花了大量时间在问“这是谁”，而真正该问的是“你能做什么”。

1.2 UA欺骗：互联网上最不值钱的“身份证明”

还有一个更大的问题：User-Agent这玩意儿，根本就不是一个可靠的“身份证明”。它只是一个字符串，任何人都可以改。

你打开桌面Chrome的开发者工具，按一下设备模拟器，UA瞬间就变成了iPhone的UA。手机上任何一个主流浏览器都提供“桌面版网站”模式，切一下UA就变成Windows Chrome。有些公司内部代理会在网关层改写UA，有些爬虫会伪装成搜索引擎，甚至不少App的WebView直接写死了自定义UA。

这意味着什么？意味着你基于UA做判断时，代码的输入是一个随时可以被篡改的字符串。你用这个字符串去推断用户浏览器的真实身份，再推断它支持什么特性，中间隔了两层不可靠的假设。第一层假设“UA可信”，第二层假设“身份能推出能力”。两层都是猜，猜错了就出Bug。

更尴尬的是，UA检测还有一个历史遗留的“名声问题”：早年间很多网站用UA做功能阻断，看到不是某个牌子就直接拒绝服务。所以浏览器厂商开始在UA里“造假”，有的去掉自家品牌标识，有的故意伪装成WebKit内核。你看到的是一个“身份证”，但这个身份证上很可能印着别人的名字。

1.3 三个致命缺陷：版本、内核、平台的对不上号

就算UA没有被篡改，它和实际能力之间也经常对不上号。我总结下来有三个经典错位：

第一，版本号不等于能力集合。同样是同一个浏览器版本，桌面平台和移动平台能力差异很大。iOS上的Safari和macOS上的Safari虽然分享同一套内核，但iOS对后台标签、内存、WebGL能力、摄像头等权限的限制比桌面严格得多。你用UA里的版本号来判断“支持不支持某个特性”，很容易误判。

第二，同品牌浏览器换内核，过去的分支全作废。最典型的就是Edge从自研内核切换到Chromium。以前很多代码判断“Edge就是旧内核”，UA一换全部失效。这种事情不是孤例，未来还会有别的浏览器换内核。你用身份做判断，本质上是赌这个品牌永远不变，这太难了。

第三，特性可能会被后向移植，也可能被前向禁用。有些旧版浏览器通过公司自带的补丁或者第三方polyfill，早早就支持了某个标准API；而有些新版浏览器出于隐私或安全考虑，主动禁用某些曾经公开的API（比如navigator.battery的Chrome版本就被移除了）。你看到的版本号是新的，但能力反而可能更少了。

这张对比表可以更清晰地看到两个方案的差异：

所以说，浏