1. 浏览器兼容性概述
1.1 我们面对的现实：浏览器市场现状
说实话，这东西从技术上不算难，但从工作量来说，我把它放在课程开头，就是想让各位同学先有个心理准备。
你可以看看手边的设备。手机里大概率是 Chrome 或 Safari。电脑上可能是 Chrome，也可能是 Edge。你很难找到两台浏览器完全一样的用户。
我们做前端开发的，从来不是只给一台机器写代码。我自己的团队做过一次统计，光是主力浏览器就涉及四大类、七八个版本。更别提还有一堆基于 Chromium 内核的“套壳”浏览器。
当前市场的主流浏览器有这么几个阵营：
| 浏览器 | 内核 | 典型平台 |
|---|---|---|
| Chrome / Edge / Opera | Blink (Chromium) | Windows / macOS / Android |
| Safari | WebKit | iOS / macOS |
| Firefox | Gecko | Windows / macOS / Linux / Android |
| QQ / 360 / UC 等国产浏览器 | 多为 Blink（部分情况有差异） | Windows / Android |
你想想看，Chromium 一家独大吗？从市占率看确实。但 iOS 生态强制使用 WebKit，这就意味着 Safari 的渲染行为谁来都得遵守。
1.2 兼容性问题，到底从哪里来？
搞清楚了市场，我们再来看看问题的根源。说白了，兼容性不是一天两天形成的。
根源其实就一个词：差异。但这个差异体现在好多层面上。
1.2.1 浏览器内核不同
每个浏览器内核，本质上就是一个“HTML/CSS/JS 翻译官”。同样一段代码，Chrome 的翻译官和 Safari 的翻译官，理解可能不一样。
WebKit 对 CSS Grid 的解析比 Blink 稍微保守一点。Gecko 呢？它对某些 CSS 标准名的支持又比较独特。我在项目中遇到过，一个 `scroll-behavior: smooth;` 的 CSS，Chrome 完美运行，换到旧版 Firefox 就没效果。嗯，这里要注意，不是 Bug，是特性支持度问题。
- 渲染引擎差异： 说白了，就是怎么把 HTML/CSS 变成像素。
- JavaScript 引擎差异： V8 (Chrome)、JavaScriptCore (Safari)、SpiderMonkey (Firefox)。ES6+ 语法的支持程度不尽相同。
- 安全模型差异： 比如 iOS Safari 对 localStorage、Service Worker、WebSocket 的限制比桌面端严格得多。
1.2.2 标准实现不同
Web 标准是 W3C 等组织制定的。但每个浏览器厂商拿到标准后，实现的“完整度”和“速度”不一样。
最典型的案例是 CSS 的 `display: flex;`。我当年做页面时，`flex` 属性还带 `-webkit-` 前缀。现在虽然几乎统一了，但有些老项目或老系统里，你还能见到它们。
| 特性 | Chrome | Firefox | Safari |
|---|---|---|---|
| CSS Grid | 完整支持 | 完整支持 | 部分老旧版本有差异 |
| ES2020+ 新语法 | 快速跟进 | 稳定推进 | 相对保守，有时滞后 |
| Service Worker | 完整支持 | 完整支持 | 限制较多（特别是 iOS） |
| WebGL 2.0 | 支持 | 支持 | 支持（但部分扩展有限） |
Intl.DateTimeFormat 的某个参数支持不全。所以，一定要验证！
1.2.3 设备和系统碎片化
这又是另一重烦恼。你可能觉得 Chrome 没问题了，但用户用的是什么系统？Windows 7 还是 Windows 11？macOS 10.15 还是 14？Android 4.4 还是 Android 14？
系统版本不同，内置的浏览器版本就不同。比如 iOS 17 以上才全面支持 PWA 的独立模式，iOS 16 开启 PWA 后，某些 API 就不能用了。
- 屏幕尺寸差异（手机、平板、折叠屏、桌面）
- 操作系统层级差异（权限、API 映射、字体渲染）
- 网络环境差异（弱网、断网、高延迟）
我个人建议，不要只看浏览器的版本号，要看你 SDK 跑在什么 OS 上。这个组合量非常大。
1.3 验证，为什么不是可选项，而是必选项？
说了这么多麻烦事，其实答案就一句话：不做验证，等于给线上埋雷。
很多同学觉得“我在 Chrome 上跑没问题啊”。这个想法很危险。你想想看，如果你的用户里 10% 用的是 Safari，3% 用的是老掉牙的 UC 浏览器，你难道指望他们都去装个 Chrome？不可能。
验证的价值体现在这几个方面：
- 规避低级错误： 比如某个 SDK 调用了
window.URL.createObjectURL，但在某些国产浏览器的旧内核中，这个 API 压根不存在。不测，就等着线上报错吧。 - 保证用户体验一致性： 你希望用户在所有浏览器上看到的按钮位置、交互反馈、加载动画都一样。验证就是做这件事。
- 减少线上故障排查成本： 如果上线后出了问题，不管是前端打日志查代码，还是后端看接口，都很被动。不如在集成阶段就把兼容性搞明白。我自己的团队，现在 SDK 集成的环节里，兼容性验证占了 1/3 的时间，但上线后的故障率降低了至少 80%。
1.4 一个简单的知识结构：兼容性验证体系
下面这张图，是我梳理的本章知识体系。你可以把它当成一张地图。我们后续的章节，都会围绕这张图展开。
从图上可以看出来，兼容性验证这件事，不是单纯地“跑一遍代码”。它需要你先理解市场，再分析根源，最后通过具体的验证手段去落地。这三者缺一不可。
理解了这些，你就明白了我们为什么要花 30 章来系统讲这个主题。接下来的课程，我会带着你从原理到实践，一步步把兼容性验证做成一套可复用的流程。