特性检测 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版本就被移除了）。你看到的版本号是新的，但能力反而可能更少了。

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

所以说，浏览器检测不是不能用，而是它天然只能做“看人下菜碟”，用身份去猜行为。这对“已知的固定问题”有效，对“未来的未知情况”完全失效。而前端兼容性开发要面对的恰恰是大量未知情况。

2. 特性检测才是“火眼金睛”：用能力探针代替身份判断

2.1 特性检测的三个层次：属性探测、执行探测、行为探测

特性检测并不是一个玄学概念，它可以拆成三个越来越深的层次。理解了这三个层次，你会发现它就是一套很朴素的“摸底线”思维。

第一层是属性探测。检查某个全局对象或对象的属性是否存在。比如：

js复制const hasIntersectionObserver = 'IntersectionObserver' in window;
const hasFetch = 'fetch' in window;

这层最简单，但它有一个隐含风险：属性存在不等于功能可用。有些浏览器为了兼容性保留了一个空壳API，属性有，调用就报错。

第二层是执行探测。不但看属性是否存在，还真的跑一遍API，用try/catch兜住异常。比如：

js复制function hasGeolocation() {
  try {
    return typeof navigator.geolocation.getCurrentPosition === 'function';
  } catch (e) {
    return false;
  }
}

这比第一层可靠得多，因为很多API的“存在性”和“可用性”是脱节的。执行探测把“存在”变成“能用”，过滤掉了空壳。

第三层是行为探测。创建真实的元素、调用真实的方法、观察返回值或副作用。这是最接近实战的一层。比如检测WebGL是否真的可用：

js复制function hasWebGL() {
  try {
    const canvas = document.createElement('canvas');
    return !!(
      window.WebGLRenderingContext &&
      (canvas.getContext('webgl') || canvas.getContext('experimental-webgl'))
    );
  } catch (e) {
    return false;
  }
}

这里canvas.getContext('webgl')返回null就说明硬件加速不可用，返回一个上下文对象才说明能用。这种探测方式直接触摸能力本身，完全不需要关心用户用的是Chrome还是Safari，是手机还是电视。

你只需要记住一个原则：探测对象是“你需要的那个能力”，而不是“能力的供应商”。

2.2 一组可以抄作业的探针代码

每次写新的探测逻辑都重新查一遍兼容性表，很烦。我习惯把常用的能力探针封装成一个模块，一次性探测完，项目里到处复用。下面这组代码可以直接抄，注释我也写清楚了：

js复制// capability.js
export const capability = {
  pointerEvents: 'PointerEvent' in window,

  touchScreen: 'ontouchstart' in window || navigator.maxTouchPoints > 0,

  webgl: (() => {
    try {
      const canvas = document.createElement('canvas');
      return !!(
        window.WebGLRenderingContext &&
        (canvas.getContext('webgl') || canvas.getContext('experimental-webgl'))
      );
    } catch (e) {
      return false;
    }
  })(),

  cssGrid: (() => {
    try {
      const el = document.createElement('div');
      el.style.display = 'grid';
      return el.style.display === 'grid';
    } catch (e) {
      return false;
    }
  })(),

  objectFit: (() => {
    try {
      const el = document.createElement('div');
      return 'objectFit' in el.style;
    } catch (e) {
      return false;
    }
  })(),

  intersectionObserver: 'IntersectionObserver' in window,

  cookieEnabled: (() => {
    try {
      return navigator.cookieEnabled;
    } catch (e) {
      return false;
    }
  })(),
};

有个细节要注意：CSS特性的探测，一定要用in el.style而不是'grid' in window，因为CSS属性挂在元素的style对象上；而且全局变量里没有CSS属性名。这种探针写法虽然笨，但它反映的是浏览器真正解析样式的能力，和UA没有任何关系。

还有一个容易被忽视的点：探针函数要写成自执行表达式（IIFE），在页面加载时就固定结果。不要在用户交互时才去探测，因为有些探测（后面会讲到）有副作用，最好一次性完成。

2.3 为什么“向前兼容”是特性检测最大的红利

我在团队里经常说一句话：“特性检测写得好，未来五年不用为浏览器升级改代码。”这不是夸张，这是特性检测最大的红利——向前兼容。

想想看：当一个新的标准化特性被某个浏览器实现时，比如IntersectionObserver在Chrome 51里落地，如果一个开发者早就用'IntersectionObserver' in window做了探测，他的代码在Chrome 51发布当天就自动“支持”新特性，不需要发版本。反过来，用UA检测的代码，得等到有人把Chrome 51加进白名单、发版、灰度、用户更新，整个链条走完才能用上。

再举一个更极端的例子：智能电视、车载浏览器、电子书阅读器、游戏机内置浏览器，这些设备的UA五花八门，有些甚至没有真正的UA。写UA白名单等于给自己挖了个无底洞。但特性检测不在乎你是谁，它只问“你认识这个API吗”。只要认识，就给你最新体验；不认识，就自动走降级方案。

这就是“火眼金睛”和“刻舟求剑”的本质区别：一种思路面向能力，一种思路面向身份。面向能力，你看到的是“这个用户环境实际能用什么”；面向身份，你看到的是“这个世界在某个时间点长什么样”——而世界一直在变。

3. 实战拆解：从“login data”热词看浏览器保存密码检测

3.1 为什么那么多人搜“检测源：login data”

最近看到不少前端同行在搜一个词：“浏览器保存帐密记录检测源:login data”。顺着这个搜索词理解一下，大家其实是在做同一个需求：怎么知道浏览器是否保存了当前网站的账号密码。

这个需求通常来自产品经理。比如用户打开登录页时，如果浏览器已经保存了这个站点的账密，我们可以在输入框旁边提示“检测到本浏览器已保存登录信息，可直接登录”，或者自动触发一次友好的填充引导。这个体验优化本身是合理的，但实现路径很容易走偏。

搜索“login data”的人，多半是看到了一些浏览器内部工具的资料，发现Chrome系浏览器会把所有保存的账号密码放在一个叫“Login Data”的SQLite数据库文件里，于是想知道前端JS有没有办法读取它。

3.2 “login data”为什么不能也不该被前端读取

直接说结论：前端不仅读不到，而且永远不应该读到。

“Login Data”是Chrome/Edge等浏览器在用户本地Profile目录下创建的一个SQLite文件，里面存着的就是浏览器保存的网址、用户名和加密后的密码。这个文件由浏览器进程管理，权限控制非常严格。网页是运行在沙箱里的，除非用户主动打开开发者工具做调试，否则页面JS没有任何API能直接读取本地文件系统，更别说这个属于浏览器私密数据区域的文件。

退一步说，就算技术上存在漏洞能让网页绕过沙箱去读这个文件，这个功能也绝不能做。因为一旦网页能读“Login Data”，意味着你访问任何一个网站时，这个网站都有可能偷走你所有网站的密码。这是整个安全体系的大忌，任何正规浏览器都会把这条路径封死。

所以，所有试图从“数据源”下手的方案，都是方向性错误。这条路走不通，也不该走通。

3.3 正经做法：用自动填充行为做能力探测

那正确的思路是什么？回到前面讲的“火眼金睛”方法论：不直接问“你存了什么”，而是观察“你做了什么”。浏览器保存了账密后，在访问对应站点时，会在输入框上发生自动填充行为。我们只需要观察这个行为。

各大浏览器在自动填充时，都会给输入框添加一个特殊样式类:-webkit-autofill。Chrome/Edge系浏览器在填充时还会触发一个animationstart事件，因为它的自动填充过程会注入一段名为“autofill”的CSS动画。利用这两个信号，我们就能不碰任何敏感数据，只凭“行为痕迹”判断发生了自动填充。

下面是一段可用代码，思路是给输入框注入一个自定义的填充动画，然后监听动画事件：

js复制// 注入自动填充动画探针
document.head.insertAdjacentHTML('beforeend', `
  <style>
    @keyframes autofill-fill {
      from { background-color: transparent; }
      to { background-color: transparent; }
    }
    input:-webkit-autofill {
      animation-name: autofill-fill;
      animation-duration: 0.1s;
      animation-fill-mode: both;
    }
  </style>
`);

function watchAutofill(input) {
  const markFilled = () => {
    input.dataset.autofilled = 'true';
  };

  // Chrome/Edge：自动填充触发注入动画
  input.addEventListener('animationstart', (e) => {
    if (e.animationName === 'autofill-fill') markFilled();
  });

  // 兜底方案：部分浏览器填充不触发动画时，用值变化和样式类兜底
  let lastValue = input.value;
  input.addEventListener('input', () => {
    if (input.value !== lastValue && input.matches(':-webkit-autofill')) {
      markFilled();
    }
    lastValue = input.value;
  });
}

watchAutofill(document.querySelector('#username'));
watchAutofill(document.querySelector('#password'));

这段代码只判断“有没有发生自动填充”，完全不读取输入框里的内容，更没有向任何地方上传数据。它把“浏览器保存了账密”这个内部状态，翻译成了一个可以在页面里观察到的行为信号，这就是特性检测思维的应用。

要注意两个执行细节。第一，这段探针脚本需要在登录表单渲染完成后立刻执行，最好在DOMContentLoaded之前就绑定监听，否则自动填充可能在你还没开始监听时就完成了。第二，一些浏览器（尤其是iOS Safari的隐身模式）出于隐私考虑，不会触发自动填充，也没有:-webkit-autofill样式，这类环境会漏报，这是隐私保护设计的必然结果，不是代码Bug，产品侧要接受。

3.4 这个案例里的特性检测思维

把这个“login data”案例再往深想一层，它其实完美展示了特性检测的完整逻辑链：

• 真实需求：知道“浏览器是否已保存本站账密”
• 错误的拆解：想办法读取浏览器保存的账密数据库（数据源）
• 正确的拆解：观察浏览器是否发生了自动填充行为（行为信号）

这就是我前面说的“行为探测”层次的实战应用。浏览器保存账密这个能力，它不会告诉你“我保存了”，但它的填充行为会暴露这个事实。特性检测的本质就是寻找“行为指纹”而不是“身份证明”。

同样值得注意的现象是，前端在这个能力上依然没有一个真正标准的API。国际标准化路径里，WebAuthn的Conditional UI和Credit Card Aotofill相关能力在逐步推进，但密码管理器自动填充的检测目前仍然主要靠行为信号。这恰恰体现了“行为探测”的价值：标准还没统一，我们就先探测行为，等标准来了再平滑切换。

4. 特性检测也有盲区：什么时候必须让浏览器检测“补位”

写到这里，千万别产生一个错觉：特性检测是万能药，浏览器检测必须扔进垃圾桶。真实情况是，特性检测也有它的盲区，有一些场景下它测不出来，这时候浏览器检测反而要“补位”。关键是搞清楚各自的边界。

4.1 数据不可见的“幽灵能力”

最典型的盲区是：属性存在，但行为被环境策略限制。这种情况下，特性检测返回的可能是“支持”，但真实环境里功能是坏的。

举几个我踩过的真实例子：

• navigator.cookieEnabled返回true，但浏览器已经限制了第三方cookie，实际写入一个第三方cookie会被直接丢弃。
• localStorage.setItem()不抛异常，但用户在隐私模式或者存储配额用尽时，写入的数据可能在页面刷新后神秘消失。
• navigator.storage.estimate()显示有50GB可用空间，但真正调用navigator.storage.persist()申请持久化存储时被用户拒绝，或者被浏览器策略直接忽略。

这些“幽灵能力”用单纯的属性探测也测不出来，因为它们的存在性是真的，但可用性是假的。这时候需要更进一步的行为探测——真的写一次数据、真的读取回来、真的发起一次请求，然后验证结果。前面讲的“三层探测”里，最高级的行为探测就是在处理这种问题。

所以在写探针时，不要满足于“属性存在”，要尽量设计成“写一个测试值，读回来看看是不是还是那个值”。比如检测localStorage是否可以持久化：

js复制function localStorageWritable() {
  try {
    const key = '__probe__' + Date.now();
    localStorage.setItem(key, '1');
    const ok = localStorage.getItem(key) === '1';
    localStorage.removeItem(key);
    return ok;
  } catch (e) {
    return false;
  }
}

这种探测虽然要付出一点I/O成本，但它测的是“真实可用性”，不是“名义可用性”。

4.2 带副作用的探测与易误判的边界

另一类盲区更隐秘：探测本身会触发副作用。你为了检测能力，反而干扰了用户正在进行的操作。

最典型的例子是AudioContext。在iOS Safari上，创建AudioContext会立刻占用音频通道，如果不调用resume()并在用户手势里播放声音，可能影响其它音频来源，甚至导致网页其他声音无法播放。所以检测“是否支持Web Audio API”时，typeof AudioContext !== 'undefined'就够了，千万别为了验证真的去初始化一个上下文实例。

还有一个非常容易误判的是触摸事件。'ontouchstart' in window在触摸屏笔记本上返回true，但这些设备用户绝大多数时间用鼠标操作。如果你的业务场景是“检测用户是否用触屏设备，来决定是否重做交互”，直接拿触摸探针做判断会让触摸屏笔记本用户看到一套为手机设计的巨按钮界面。更合理的是结合屏幕尺寸、指针精度做综合判断，而不是单一能力探测。

这提醒我们：特性检测检测的是“环境具备的能力”，不是“用户的使用方式”。能力存在不代表用户在用，这两个问题不能混为一谈。

4.3 浏览器检测的正确归宿：已知Bug补偿，而非兼容预判

那么浏览器检测到底应该放在哪里？我用了几年时间，最后把它的使用场景收敛到三个：

第一，已知Bug的定向修复。某个WebView版本存在固定行为异常，无法用能力检测覆盖，只能对UA做定向补丁。但补丁生效前，还要再验证一下该Bug是否真的存在，避免误伤其他浏览器。

第二，统计与分析。运营看板想知道“我们用户里Safari占多少”，这时候用UA做归因是合理的——这是统计场景，不涉及功能分支，误判的代价远低于业务Bug。

第三，最后一公里兜底。当能力检测完全无法区分某些边界情况时（比如某些冷门国产浏览器的特定渲染行为），才把UA当成一个补充信号，和特性检测结果一起参与决策，而不是单独作为决策依据。

我给自己定了一条判断标准：“如果用浏览器检测是为了回答‘要不要用新特性’，说明能力检测没写对；如果是为了回答‘是不是已知的坑’，那才算用对了地方。” 这句话也分享给你，以后写代码时可以对照着问自己。

5. 工程化落地：搭一套能自愈的检测体系

聊了一大堆原理和案例，最后落到工程实践。单次检测很简单，但一个正经项目里，兼容性检测必须被设计成一套体系，否则过两年就会变成一团乱麻。

5.1 从一次探针到一套策略：三层结构设计

我的习惯是把检测拆成三层，各司其职：

• 能力共识层：页面加载时集中探测一次，把结果存到模块级变量里。所有业务代码都通过这个共识层读取检测结果，不要散落在各处裸写探测逻辑。
• 降级策略层：为每个关键特性配置降级方案。比如CSS Grid不可用时，退回Flexbox；Object Fit不可用时，退回背景图方案。降级方案要写清楚“为什么降级、什么时候回退”。
• 运行时反馈层：通过错误监控把真实的兼容性Bug收集起来，定期反向修正能力共识层和降级策略层。

这三层配合起来，才能形成一个不断进化的体系。举个代码示例：

js复制// polyfill-degrade.js
import { capability } from './capability';

export function getImageFit() {
  if (capability.objectFit) return 'cover';
  return 'background-size'; // 降级到背景图方案
}

export function getSticky() {
  if (capability.positionSticky) return 'sticky';
  return 'fixed'; // 降级到固定定位
}

业务代码里调用getImageFit()而不是自己判断objectFit，这样将来某个浏览器真正普及了object-fit，我们只需要在能力探针里加一行，所有业务自动受益。

5.2 缓存、降级、熔断：让检测结果有保鲜期

很多团队会想到把检测结果缓存到localStorage里，减少下次加载的探测开销。我的建议是：可以缓存“支持”的结论，尽量别缓存“不支持”的结论。

原因很简单：浏览器是会升级的。今天探测到IntersectionObserver不支持，把“不支持”写进localStorage缓存，三个月后浏览器升级支持了，但缓存还在，你的代码依然走降级方案。而“支持”的结论相对可靠，因为能力一旦存在，短期内不太会消失（虽然有前面提到的废弃API，但概率低得多）。

更稳妥的做法是：只在当前会话内，用内存变量缓存探测结果。每次刷新页面重新探测一次，开销很小，但换来了“保鲜期”。如果实在想用localStorage，给缓存加上版本号，浏览器大版本变化时更新缓存。

我还加了一层“运行时熔断”机制：如果某个功能在运行时真的报错了，错误监控上报的同时，把之前探测的“支持”结论推翻，下次重新探测。这个机制能自动清理缓存里的“过期结论”。

5.3 避坑清单与监控思路

最后整理一个避坑清单，都是我在实际项目里踩过的，或者看到同行踩过的：

监控层面的思路也顺带说一句。不要只监控JS报错，建议在错误上报时带上能力探针的检测快照——capability对象里那几个布尔值全部上报。这样当某天某个功能突然崩了，你能马上看到“报错用户里capability.webgl = false的比例是否异常”，快速区分“是所有用户都崩了”还是“某个能力缺失的用户崩了”。这种数据联动，比单纯看报错堆栈高效得多。

我见过很多团队把兼容性处理做成“补丁摞补丁”的样子：今天发现浏览器版本不对，加一条UA判断；明天发现UA又变了，再加一条。整个代码库像一张多层拼贴画。用这套三层体系重构之后，兼容性逻辑被收敛到了几个文件里，业务代码不再关心浏览器是谁，只关心“这个能力能不能用”。这个改变带来的维护成本下降，是立竿见影的。

回顾这些年在兼容性开发上踩过的坑，我最大的体会就是：前端的世界里，浏览器身份是幻觉，能力才是真相。与其花时间预测一个变化不定的未来，不如用一个简单的问题问住现在——“这个环境，你到底能不能做这件事？”特性检测给我们的，正是这种直面真实的能力。遇到任何兼容性需求，先问自己一句：我是要问它“能做什么”，还是要问它“是谁”？想清楚这个问题，你就知道该用火眼金睛，还是该用刻舟求剑了。

最后再分享一个实用小技巧：在你的团队代码共享库里放一份标准的capability.js探针文件，每次新项目直接引入，遇到新特性就往上加一行探针。让检测能力成为团队的基础设施，而不是每个项目各自为战。时间久了，这份文件就是你团队在前端兼容性上积累下来的、真正的“火眼金睛”。