有一次，我接手了一个运行了好几年的老项目,产品经理突然跑过来问我：“老师，为什么这个按钮在 Chrome 里能点，在 Safari 里却不显示？”

我打开代码一看，发现前同事写了这样一段逻辑：

我当时就笑了,这就好比你去餐厅吃饭，服务员问：“您会用筷子吗？”

你回答：“我来自中国。”，服务员于是默认你会用筷子，但问题是，来自哪里，和会不会用筷子，根本不是一回事。

浏览器检测也是如此，我们真正应该关心的，通常不是“你是什么浏览器”，而是你的浏览器有没有能力完成我需要的事情？

这就是 JavaScript 客户端检测中非常重要的一种方法——能力检测（Capability Detection）。

什么是能力检测？

所谓能力检测，简单来说就是不关心浏览器的身份，只检查当前环境是否具备某项功能。

例如，我们想判断浏览器是否支持 geolocation：

这里完全没有判断 Chrome、Firefox、Safari，也没有判断浏览器版本，我们只问一个问题：navigator 有没有 geolocation 这个能力？这就是能力检测。

再比如，我们想判断浏览器是否支持某个 API：

或者检查某个对象上的方法：

这时候，我们的代码思路发生了一个很重要的变化：

• 浏览器检测： 你是谁？ 

• 能力检测： 你会什么？

对于前端开发来说，后者往往更加可靠。

为什么不推荐直接判断浏览器？

很多刚开始学习 JavaScript 的同学，都喜欢使用 navigator.userAgent，例如：

看起来很简单，但这里存在一个很大的问题：User-Agent 是浏览器自己提供的一段身份信息，并不是能力证明。

更麻烦的是，现代浏览器的 User-Agent 字符串越来越复杂，而且不同浏览器之间可能故意包含其他浏览器的关键字，以兼容历史网站，所以：

• 看到 Chrome ≠ 一定支持某个功能

• 同样不是 Chrome ≠ 一定不支持某个功能

假设我们真正需要的是 WebSocket，正确的问题应该是：

而不是：

因为我们真正关心的是 WebSocket 能不能用，浏览器叫什么名字，只是间接信息。

能力检测的核心思想

能力检测其实可以抽象成一个非常简单的模型：

例如：

这段代码并不关心浏览器是什么，它只关心当前环境有没有 localStorage？

这就是能力检测最核心的思想。

安全能力检测

能力检测虽然简单，但真正写生产代码时，还需要考虑一个问题：

“存在”不代表“真的能正常使用”。

这就是安全能力检测，例如：

看起来没问题，但某些运行环境下，即使 localStorage 属性存在，实际访问或者写入也可能失败。

所以更安全的方式是：

这里做了两层判断：

• 第一层：window.localStorage，看看能力是否存在。

• 第二层：setItem()，真正尝试执行一次。

只有执行成功，才认为这个能力真正可用。

这就像检查一辆汽车：

• 你不能只看：“这辆车有发动机。”

• 还应该：“钥匙能不能拧动？发动机能不能启动？”

​

为什么“类型检测”非常重要？

能力检测中，我们经常会看到这样的代码：

为什么不直接：

因为 JavaScript 中的属性值可能存在，但类型并不符合预期，例如某个属性可能是 undefined，也可能是 null，甚至可能是一个普通值，因此：

• 对于函数能力通常建议使用：typeofxxx==="function"

• 对于属性是否存在，则可以使用："xxx"inobject 或者 object.xxx !==undefined

不过二者并不完全等价。

例如："toString" in Object.prototype，结果是 true，因为属性可能来自原型链，如果我们只想检查对象自身的属性，还可以使用 Object.hasOwn(object, "xxx")。

所以能力检测并不是简单地“看到属性就认为支持”，而是要根据检测目标选择合适的方法。

常见能力检测方式

实际开发中，我们经常会遇到下面几类检测。

这里尤其要注意的是能力检测不是万能的，如果一个 API 存在，但由于权限、用户设置、浏览器策略等原因不能正常工作，仅仅检查 API 是否存在是不够的。

因此生产环境中的能力检测，经常是：

这才是一套更加完整的方案。

基于能力检测进行浏览器分析

说到这里，很多人可能会产生一个疑问：小米，你刚才不是说不要判断浏览器吗？那怎么分析浏览器？

其实这里有一个非常重要的区别：我们可以分析浏览器能力，但不要把浏览器身份当成能力的替代品。

例如，我们可以建立一个能力矩阵：

可能得到：

这时候，我们得到的不是：这是 Chrome。而是：

• 这个客户端支持 Fetch 

• 支持WebSocket 

• 支持 Worker 

• 支持 Geolocation 

• 支持 LocalStorage

这个信息其实更加有价值，因为业务代码真正关心的就是这些能力。

能力检测可以决定功能降级

能力检测最重要的价值之一，就是渐进增强和优雅降级，例如：

再比如：

这时候，用户不会因为浏览器不同而直接看到：“您的浏览器不支持，请升级浏览器。”

而是：

这就是更加成熟的前端设计。

能力检测不是“浏览器检测”的升级版，而是思维方式的改变

我越来越觉得，能力检测真正重要的地方，并不是某一段 JavaScript API，它改变的是我们的开发思维。

以前我们可能习惯这样写：

• 如果是 Chrome → 使用方案 A 

• 如果是 Safari → 使用方案 B

• 如果是 Firefox → 使用方案 C

但随着浏览器越来越复杂，这种代码很容易变成一团“浏览器判断泥潭”，更好的方式是：

• 支持能力 A → 使用方案 A 

• 不支持能力 A → 使用方案 B

这实际上是一种面向能力编程。

浏览器只是承载 JavaScript 的“机器”，我们真正需要关注的是：这台机器到底能做什么？

​

总结

如果面试官问你：“JavaScript 客户端检测中的能力检测是什么？”

可以从三个层次回答。

• 第一，能力检测就是直接检查当前运行环境是否具备某项能力，而不是通过 User-Agent 判断浏览器身份。

• 第二，安全能力检测不仅要判断属性是否存在，还要根据实际情况进行类型检查、真实调用以及异常处理，因为“API 存在”并不一定意味着“API 可用”。

• 第三，基于能力检测进行浏览器分析，可以把浏览器分析从“你是什么浏览器”，转变成“你支持哪些能力”，然后根据能力动态选择功能和降级方案。

就像招聘一个程序员，我们真正应该问的不是“你毕业于哪所学校？”，而是“你会 Java 吗？会并发吗？会 Redis 吗？遇到线上故障能不能解决？”

浏览器也是一样，名字只是身份，能力才决定我们到底能让它做什么。

END

阅读原文：点击这里