跨浏览器兼容性测试用于检查网站的功能和布局能否在你所支持的每一种浏览器、浏览器版本、操作系统和设备上保持一致，并包括修复出现的问题。常规的跨浏览器测试关注的是测试流程和工具；而兼容性测试关注的是差异本身：某个浏览器尚未支持的 CSS 特性、在 Android 上行为不同的日期选择器，或是在第三方 Cookie 被屏蔽时失效的登录功能。
什么是跨浏览器兼容性测试？
如果你依赖的每项功能都得到支持，并且渲染效果符合预期，那么这个浏览器就与你的网站兼容。兼容性测试（常简称为 CBT）要回答三个问题：
- 我们支持哪些浏览器和版本？
- 我们使用的每项功能在这些浏览器中是否都能正常工作，或者在不支持时能否平稳降级？
- 最新的浏览器版本或我们最近的部署是否破坏了某些功能？
更广义的兼容性测试还可以涵盖操作系统、硬件、屏幕阅读器和慢速网络，但对网站而言，大多数问题都出在浏览器一侧。
为什么兼容性在 2026 年依然重要
- 你的用户分散在不同的浏览器引擎上。根据 StatCounter 2026 年 9 月的数据，Chrome 占全球浏览器使用量的 66.4%，Safari 占 18.3%，Edge 占 6.0%，Firefox 占 2.8%，Samsung Internet 占 2.3%。在移动端，Safari 占 24.7%；在美国，Safari 在所有设备上的占比为 30.4%。
- iPhone 上的所有浏览器都运行 WebKit。iOS 上的 Chrome、Firefox 和 Edge 都使用苹果的引擎（欧盟地区有限例外），因此 Safari 的一个缺陷会影响所有 iPhone 用户，无论他们选择了哪款浏览器。
- 新功能的落地时间各不相同。新的 CSS 和 JavaScript 特性在各浏览器中按各自的节奏发布，而旧版本还会长期留存在不再更新的设备上。
- 搜索与转化。Google 索引的是页面的移动版本，因此在手机上出现布局错乱，既会影响访客体验，也会影响搜索可见度。
第一步：制定浏览器支持矩阵
你不可能支持所有浏览器，所以要把真正支持的范围写下来。可以从网站分析数据入手，把浏览器分成几个层级：
| 层级 | 典型浏览器 | 承诺 |
|---|---|---|
| A：完全支持 | 当前版本的 Chrome、Safari（Mac 和 iPhone）、Edge 和 Firefox；如有 Android 流量，还包括 Samsung Internet | 所有功能正常，外观与设计一致；每次变更都运行自动化测试 |
| B：功能可用 | 仍出现在你的分析数据中的旧版本 | 核心流程可用；允许存在细微的视觉差异 |
| C：基本可用 | 其他所有浏览器 | 内容可读，表单可提交 |
把这份矩阵保存为 Browserslist 配置，这样 Autoprefixer 和 Babel 等构建工具就会针对同一批浏览器进行处理。Baseline 是个实用的捷径：标记为“Baseline 广泛可用”的功能，已在所有核心浏览器（桌面和移动端的 Chrome、Edge、Firefox 和 Safari）中稳定运行至少 30 个月，因此大多数网站无需回退方案即可使用。
如何发现并修复兼容性问题
- 开发前先查支持情况。在 MDN 上查询新功能，其页面提供浏览器兼容性表格和 Baseline 状态；也可以使用 Can I use。Baseline 项目则说明了该状态的定义方式。
- 检测功能，而不是检测浏览器。用
@supports包裹较新的 CSS，并在 JavaScript 中先确认某个 API 存在再调用，而不是通过 User-Agent 字符串去猜测。 - 采用渐进增强。先让内容和表单在基础 HTML 与 CSS 下正常工作，再逐层叠加新功能。
- 将常规修复自动化。Autoprefixer 负责添加厂商前缀，Babel 和 polyfill 负责兼容旧版 JavaScript 引擎，而 eslint-plugin-compat 之类的代码检查工具会在代码用到你的 Browserslist 目标不支持的功能时发出警告。
- 在三大引擎中都进行测试。Playwright 可以在 Chromium、Firefox 和 WebKit 中运行同一套测试，其截图对比功能还能发现布局偏移。
- 在真实设备上确认。模拟器和响应式设计模式适合作为初步检查，但屏幕键盘、触控、滚动和视频在真实手机上的表现并不相同。可以使用自己的设备，或 BrowserStack、TestMu AI（原 LambdaTest）、Sauce Labs、BitBar 等云端设备集群。
- 开启隐私保护后再测试。Safari 的跟踪防护、Firefox 的严格模式以及 Brave 的 Shields 都可能屏蔽你网站所依赖的脚本、Cookie 和嵌入内容。
2026 年常见的兼容性问题
| 问题 | 出现位置 | 常见修复方法 |
|---|---|---|
| 整屏高度的区块跳动或被工具栏遮挡 | 移动端浏览器，尤其是 iPhone 上的 Safari | 使用 dvh 等动态视口单位代替 vh |
| 较新的 CSS 特性被忽略 | 尚未支持该特性的浏览器、较旧的设备 | 查看 Baseline 状态，并添加 @supports 回退方案 |
| 日期、时间和下拉选择输入框的外观与行为不一致 | 所有浏览器，因为各自使用原生选择器 | 接受原生控件，或使用经过充分测试的组件库 |
| 视频无法自动播放或内联播放 | 移动端浏览器和 Safari | 仅对静音视频启用自动播放，并为 iPhone 添加 playsinline |
| 嵌入式登录、支付或聊天组件失效 | 限制第三方 Cookie 的 Safari、Firefox 和 Brave | 优先采用第一方流程或 Storage Access API，并在默认隐私设置下测试 |
| 文本换行方式不同，按钮内容溢出 | Windows、macOS 和 Android 上字体及字体渲染的差异 | 定义备用字体，并在按钮和菜单中预留空间 |
跨浏览器兼容性检查清单
- 已写出支持矩阵，并保存为 Browserslist 配置。
- 新功能在使用前已在 MDN、Can I use 或 Baseline 上查验。
- 对未达到 Baseline 广泛可用状态的功能已准备回退方案。
- 自动化测试在 Chromium、Firefox 和 WebKit 中均已通过。
- 表单、视频和滚动已在真实的 iPhone 和 Android 手机上检查过。
- 登录、支付和嵌入内容已在默认隐私保护开启的情况下测试过。
- 针对特定地区的页面和机器人检测，已从其他地点并使用不同的浏览器指纹进行测试（参见测试方法）。
- 每次浏览器发布重大版本后重新运行测试。
常见问题
如果我的网站在 Chrome 中看起来没问题，还需要做兼容性测试吗？
需要。Chrome 约占全球浏览器使用量的三分之二，但仅 Safari 就占美国访问量的近三分之一，而且 iPhone 上的所有浏览器都运行在 Safari 的引擎之上。只在 Chrome 中测试，会让相当一部分访客的体验得不到检验。
应该多久做一次兼容性测试？
每次代码变更以及浏览器发布重大版本之后，都应运行自动化检查；在重要上线或改版之前，再在真实设备上做一轮手动测试。
兼容性测试成本高吗？
不一定。Playwright、Selenium 和 Cypress 都是免费的，MDN、Can I use 和 Baseline 的数据同样免费。付费的云端设备集群主要是帮你省去自行采购和维护设备实验室的麻烦。
跨浏览器测试和兼容性测试有什么区别？
跨浏览器测试是在多个浏览器中进行测试的整体流程，详见我们的跨浏览器测试指南。兼容性测试则更聚焦于你所使用的具体功能和代码是否受支持，以及如何修复或绕过这些差异。
