浏览器兼容性基础：内核差异与检测手段
做前端这么多年，我最大的感触就是——浏览器从来不是"一个标准"。每个浏览器背后都有不同的内核，它们对 CSS、JS、DOM 的解释或多或少都有出入。你不了解这些差异，兼容性问题就会像地雷一样，踩一个炸一个。
一、四大主流内核：谁是谁？
目前市面上最活跃的浏览器内核，就那么四个。我把它整理成了一张表，你看一眼就明白了。
| 内核名称 | 代表浏览器 | 渲染引擎 | JS 引擎 |
|---|---|---|---|
| Blink | Chrome、Edge（新版）、Opera、Brave | Blink | V8 |
| WebKit | Safari、旧版 Chrome、旧版 Opera | WebKit | JavaScriptCore（Nitro） |
| Gecko | Firefox、Tor Browser | Gecko | SpiderMonkey |
| Trident / EdgeHTML | IE（Trident）、旧版 Edge（EdgeHTML） | Trident / EdgeHTML | Chakra |
简单说几句：Blink 是从 WebKit 分支出来的，Chrome 和 Edge 现在都用它，市场份额最大。WebKit 主要是 Safari 在用，macOS 和 iOS 下你得重点照顾它。Gecko 是 Firefox 的老底子，对 Web 标准一直很激进，但有一些自己的特殊行为。Trident 已经算历史遗留了，IE 退休后，你只需要在极少数政企内网里跟它打交道。
个人经验：我有一回在 Windows 上开发，所有浏览器测试都没问题，结果用户用 Mac 版 Safari 打开，整个页面布局全乱了。查了半天发现是 flexbox 的 gap 属性在旧版 WebKit 里不支持。嗯，从那以后，我养成了习惯——开发机上至少装 Chrome、Firefox、Safari 三个浏览器。
二、内核差异带来哪些实际问题？
内核差异不是纸面上的概念，它直接影响你的代码能不能跑。我挑几个最常见的坑说说。
2.1 CSS 前缀与特性实现
早期每个内核都自己搞私有前缀：-webkit-、-moz-、-ms-。现在很多属性已经标准化了，但仍有例外。比如 scroll-behavior 在旧版 Chrome 里需要 -webkit- 前缀，而 Firefox 直接支持。
2.2 JavaScript API 差异
Array.prototype.flat：Chrome 69+、Firefox 62+ 支持，但 IE 全系没有。IntersectionObserver：Safari 12.1 才开始支持，早期版本得用 polyfill。Promise.allSettled：Node.js 12.9+、Chrome 76+，但 IE 和旧 Edge 直接报错。
2.3 Web 安全特性
SameSite Cookie 属性的默认值，Chrome 80 之后变成 Lax，而 Firefox 和 Safari 的默认值不同。这曾经导致我线上一个跨站登录流程在 Chrome 下失效，用户反馈说"明明登了，刷新又没登录"。排查下来就是 SameSite 的锅。
一句话总结：内核差异主要分布在 CSS 渲染、JS API 可用性、安全策略、DOM 行为这四个维度。不要假设"最新的 Chrome 能跑"就等于所有浏览器都能跑。
三、检测用户代理（User-Agent）——老办法，但别滥用
navigator.userAgent 是浏览器自报家门的字符串。比如：
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36你能从中解析出浏览器名称、版本、内核、操作系统。但我要提醒你——这个字符串可以伪造。用户改了 User-Agent 你就抓瞎了。而且 IE 11 的 User-Agent 长得很像 Mozilla，容易误判。
我个人建议：只在两种情况下用 User-Agent 检测：
- 需要区分操作系统（比如 Android 与 iOS 的下载链接跳转）。
- 需要识别 IE 这种已经淘汰但仍有遗留的系统。
其他场景，尤其是特性检测能搞定的，就别碰 User-Agent。
避坑指南：我曾经在某个项目中，用正则从 User-Agent 里匹配 "Chrome" 来启用某个只有 Chrome 支持的功能。结果新版 Edge 的 User-Agent 包含 "Chrome" 字样，Edge 用户也被判为 Chrome 了。功能倒是能跑，但 Edge 特有的一些 bug 没被绕过，出了不少问题。
四、特性检测——现代前端的正确答案
特性检测的思路很简单：你直接问浏览器"这个能力你有吗？"而不是问"你叫什么名字？"。不管内核是谁，只要支持就用，不支持就降级或提示。
常见的写法：
if ('IntersectionObserver' in window) {
const observer = new IntersectionObserver(callback);
} else {
// 用 getBoundingClientRect 做 fallback
}这种做法的好处很明显：
- 不受 UA 伪造影响。
- 未来新的浏览器进来，只要支持这个特性，代码直接生效。
- 逻辑清晰，维护简单。
常用的检测方式：
| 检测目标 | 代码示例 | 注意事项 |
|---|---|---|
| CSS 特性 | CSS.supports('display', 'grid') | IE 不支持 CSS.supports |
| JS API | 'fetch' in window | 注意有些 API 需要 typeof 避免未定义报错 |
| HTML 属性 | 'placeholder' in document.createElement('input') | 动态创建元素再检测属性存在性 |
一个小技巧：如果同一特性在不同内核下实现有细微差异（比如 Event 构造函数的参数），可以用 try/catch 包裹。先试试标准写法，报错了再走 polyfill 路径。这是我常用"检测+尝试"组合拳。
五、一张图理清本节核心
下面这张图帮你快速掌握"兼容性检测"的知识体系。怎么选择检测方式，优先级是什么，一看就明白。
六、实际工作中的选择策略
我总结了三条原则，按优先级排：
- 能特性检测，绝不 UA 检测。 —— 这是铁律。
- 特性检测无法覆盖的（比如操作系统判断），再上 UA。 但解析完 UA 之后，最好还是用特性检测去确认那部分能力。
- 别自己手写 UA 解析库。 用
ua-parser-js或bowser这种成熟库，它们处理了边缘情况（比如 Edge、Opera 的伪装）。
我个人的做法：在项目入口写一个 detect.js，把主要 API 的检测结果缓存到全局对象里。后续代码直接读缓存，不用每次都检测。这样既保证性能，又统一了检测逻辑。
另外提一嘴，现在很多工程化工具（如 Babel、Autoprefixer、Polyfill.io）已经帮你处理了部分兼容性差异。你只要在配置里指定目标浏览器（比如 "last 2 versions, not dead"），工具会自动注入前缀和 polyfill。但工具不能覆盖所有场景，尤其是一些运行时行为差异（比如 addEventListener 在 IE 里的 this 指向），还是得靠人工写检测代码。
七、多浏览器的调试手段
光检测还不够，你得在真实环境里验证。我的调试组合是：
- 本地开发：用 Chrome DevTools 自带的设备模拟，可以快速切换 Safari、Firefox 的 UA 和视口。
- CI 自动化：跑 Playwright 或 Puppeteer，同时启动 Chrome、Firefox、Edge 的 headless 模式，用快照对比差异。
- 真实设备测试：遇到老版本 Safari 或 IE，我会用 BrowserStack 或 Sauce Labs 远程虚拟机。虽然要付费，但省了买很多设备的钱。
曾经踩过的坑：有一次我用模拟器测试 iOS Safari，页面表现正常。上线后用户反馈说点击按钮没反应。后来发现模拟器的软键盘行为与真机不同——真机上弹出键盘时 window.innerHeight 会变化，而我的布局没做适配。那次之后，只要涉及键盘交互，我一定在真机上测一遍。
好了，这一章我们就聊到这里。你先把这四种内核的差异记住，再把特性检测这个思路刻进脑子里。后面几章我们会深入具体的兼容性场景，比如 CSS 布局、JS API 的降级方案，到时候你会发现在这一章打下的基础特别有用。