为什么需要API差异适配？核心概念与价值
一个老生常谈的问题：浏览器不统一
你打开控制台，写了个 navigator.mediaDevices.getUserMedia，Chrome 上跑得挺好。丢给测试，小姐姐说「白屏了」，一看是 Safari。
说实话，这种场景太常见了。从事前端开发越久，你越会发现一个事实：浏览器厂商对同一套 API 的实现，从来就没有整齐划一过。
这种差异体现在哪？我简单列几个方向：
- 存在与否 —— 某个 API，这个浏览器有，那个没有
- 行为不同 —— 接口都在，但参数含义、返回格式不一样
- 实现有 bug —— 规范说 A，浏览器跑成 B
- 版本断层 —— 老版本有，新版本移除了，或者反过来
你想想看，如果你的页面跟浏览器 API 是「硬绑定」的，那一旦遇到不支持的环境，整个功能就挂了。这显然不行。
核心概念先理一理
做 API 差异适配，说白了就是两件事：知道差异在哪儿，以及怎么优雅地处理它。这里面有几个关键概念，我建议你牢牢记住。
| 概念 | 一句话解释 | 举个栗子 |
|---|---|---|
| 特性检测 | 判断当前环境是否有这个功能 | if (window.fetch) { … } |
| 能力检测 | 判断这个功能能不能按预期工作 | 判断 addEventListener 是否 attach 成功 |
| 浏览器嗅探 | 通过 UA 字符串识别是什么浏览器 | navigator.userAgent.indexOf('Chrome') |
| 降级方案 | API 不支持时，退而求其次的实现 | 不支持 IntersectionObserver 时回到 scroll 监听 |
| Polyfill | 用旧技术模拟新 API | core-js 帮你补上 Array.prototype.flat |
我的一个原则：优先用特性检测，能不用 UA 嗅探就别用。UA 字符串太容易被伪造了，我自己就在一个项目上吃过这个亏——用 UA 判断 iOS 版本，结果用户刷了个越狱固件，版本号变了，功能直接崩了。从那以后，我再也不敢把 UA 当主要判断依据。
API 差异适配到底解决了什么问题？
说得大一点，它保证了你写的代码在不同的浏览器里都有「合理的体验」。说得实在一点，它可以帮你避免很多线上故障。
这里我梳理了几个核心价值：
- 功能可用性 —— 核心功能不能因为浏览器不同就丢失。比如不支持
ResizeObserver，至少得能监听window.resize。 - 体验一致性 —— 不是所有地方都能做得一模一样，但至少不能出现白屏、报错、按钮点不动这种问题。
- 渐进增强与优雅降级 —— 支持好的浏览器体验好一点，老浏览器也能用。我建议用渐进增强的思路去设计：先写一个最基础的版本，再往上加能力。
- 降低维护成本 —— 适配方案做好了，你再也不用为某个古早浏览器的奇葩问题单独改代码了。一次性解决，一劳永逸。
- 代码可预测性 —— 你的逻辑不会因为浏览器不同而突然走不通。每一段代码都有兜底，心理踏实很多。
一个小经验：我在构建内部工具库的时候，会把所有 API 的检测结果提前缓存成一个对象。比如 const supported = { intersectionObserver: 'IntersectionObserver' in window, … }。这样业务代码里直接读这个对象，干净又高效。
一张图看清适配逻辑
下面这张图展示了 API 差异适配的典型决策路径。核心思路就是从「检测」到「降级」，一条清晰的路。
这章我希望你带走的东西
API 差异适配不是黑魔法，它只是一套有章可循的处理策略。核心就三点：
- 知道差异存在，别假装所有浏览器都一样
- 优先检测能力，而不是猜浏览器名字
- 永远准备一个兜底方案，哪怕只是弹个提示
我曾经踩过的坑：给某个老版本 iOS 做适配时，误以为 Array.from 是「标准 API，肯定有」。结果在用户手机上直接报错了。从此我养成了一个习惯——只要是在低版本浏览器覆盖范围内，所有 ES2015+ 的方法我都会显式检测一遍，或者直接上 polyfill。别太相信「标准」两个字，浏览器才不会跟你讲道理。
说白了，这章就是在给后面的内容打地基。地基稳了，后面讲特性检测、讲 polyfill、讲降级方案的时候，你才会有「啊，原来是为了解决这个」的感觉。