引言
浏览器兼容性经常被理解为“让页面在所有浏览器里长得一样”。但在实际项目中，这个目标既昂贵，也很难长期维护。浏览器会持续更新，操作系统和 WebView 的组合越来越多，用户还可能使用缩放、键盘、辅助技术或隐私扩展。
因此，兼容性更应该被理解为：在明确的支持范围内，让用户完成最重要的任务；对于暂时无法支持的能力，提供可接受的降级体验。
这篇文章不列一张固定的浏览器版本清单，而是结合国内用户的设备、浏览器和 WebView 使用现状，梳理我会如何考虑浏览器兼容性。
兼容的不是一个版本号
一个页面最终的表现，通常同时受到下面几层因素影响：
| 层面 | 需要关注的内容 | 常见结果 |
|---|---|---|
| HTML | 元素语义、表单行为、默认样式 | 内容是否能阅读，链接和表单是否能正常使用 |
| CSS | 语法、布局、单位、绘制实现 | 是否错位、溢出，或者整条规则被忽略 |
| JavaScript | 语法和 Web API | 脚本报错、交互失效 |
| 浏览器内核 | Blink、WebKit、Gecko 的实现差异 | 同一属性在不同浏览器中表现不一致 |
| 运行环境 | 移动端、WebView、权限、安全上下文 | 剪贴板、通知、全屏等能力不可用 |
| 用户设置 | 缩放、键盘操作、减少动态效果 | 页面是否仍然可用、可读、可访问 |
所以，“Chrome 能用”并不能直接推出“所有 Chromium 浏览器都没有问题”。同一个内核在不同操作系统上的字体、输入法、滚动条和权限策略也可能不同；而 iOS 上的 Safari 和应用内 WebView，还要额外考虑移动端 WebKit 的限制。
先定义支持范围
从用户和业务开始
在选择技术方案之前，先回答几个问题：
- 用户主要使用桌面端还是移动端？
- 是否必须支持某个企业内网浏览器、旧版 WebView 或国产浏览器？
- 哪些功能是“没有它就无法完成任务”的？
- 出现兼容性问题时，可以接受功能降级，还是必须阻止发布？
“支持”也不是只有支持和不支持两种状态，可以分成三个层级：
- 完整支持：布局、交互和视觉表现都在验收范围内。
- 核心可用：允许视觉细节或增强交互降级，但用户仍能阅读、导航或提交核心操作。
- 不在支持范围：不投入专门的兼容性成本，也不对该环境作出承诺。
对于公开站点，一个实用的起点是覆盖主流桌面浏览器和移动端浏览器的近期版本，再根据访问统计调整范围。不要为了一个理论上可能存在的用户，长期背负整个旧浏览器生态的维护成本；如果业务确实要求支持，则应该把它写进需求和测试矩阵，而不是依赖开发人员的记忆。
按内核安排测试
浏览器名称很多，但测试时可以优先覆盖渲染内核和真实设备：
| 优先级 | 环境 | 目标 |
|---|---|---|
| P0 | Chrome、Edge、Firefox、macOS/iOS Safari | 页面核心功能完整可用 |
| P0 | Android Chrome | 移动端布局、触摸和滚动正常 |
| P1 | 访问统计中占比较高的 WebView | 验证登录、分享、返回等宿主行为 |
| P2 | 旧版浏览器或特殊内核 | 至少保证明确的降级结果，或明确不支持 |
这里的版本号不应该永久写死。随着时间推移，支持矩阵需要根据用户数据、浏览器市场变化和项目依赖一起更新。
核心功能不要依赖新特性
HTML 先保证内容和语义
兼容性成本最低的方案，往往是使用浏览器原生能力：
- 跳转使用
<a>，按钮操作使用<button>； - 表单控件配合
<label>和合适的type； - 图片提供有意义的
alt，装饰图片使用空的alt； - 内容按照标题层级组织，而不是只依靠视觉样式；
- 不把所有交互都绑定在
div的点击事件上。
原生元素不仅在不同浏览器中更稳定，也天然获得键盘操作、辅助技术和部分移动端行为。先写出没有 JavaScript 也能理解的 HTML，再在上面增加交互，通常比在最后补救可访问性更省成本。
CSS 用回退值承载基础体验
新 CSS 特性适合用来改善体验，但不应该成为阅读和导航的唯一入口。比如动态视口单位在移动端更准确，可以保留旧单位作为回退：
.page {
min-height: 100vh;
min-height: 100dvh;
}不支持 100dvh 的浏览器会使用第一条规则，支持的浏览器使用第二条规则。对于模糊、装饰背景等非核心效果，也可以用 @supports 做渐进增强：
.card {
background: rgb(17 24 39 / 0.95);
}
@supports (backdrop-filter: blur(12px)) {
.card {
background: rgb(17 24 39 / 0.7);
backdrop-filter: blur(12px);
}
}需要注意，回退不是把所有新语法都手写两遍。应该先判断它影响的是核心布局，还是锦上添花的视觉效果。核心布局可以选择更成熟的 Flex 布局，装饰效果则可以在不支持时直接消失。
JavaScript 区分语法和 API
构建工具可以转换一部分 JavaScript 语法，但它不会自动补齐所有 Web API。例如，optional chaining 的语法转换，并不等于自动提供 Promise、fetch、IntersectionObserver 或 Clipboard API。
使用能力之前应做特性检测，而不是根据 User-Agent 猜浏览器：
async function copyText(text) {
if (window.isSecureContext && 'clipboard' in navigator) {
await navigator.clipboard.writeText(text)
return true
}
return false
}如果复制功能是业务核心，可以在返回 false 后提供文本框选中、手动复制等备用路径；如果它只是文章页的辅助功能，那么提示“复制失败”并保持页面其他内容可用，也可能是更合适的取舍。
特性检测的重点不是“把每个 API 都补齐”，而是让不支持某项能力的用户仍然有路可走。只有在用户群体和业务价值明确时，才值得引入 polyfill，并评估它带来的包体积和维护成本。
当前国内浏览器使用现状
移动端是主入口，但桌面端不能忽略
根据中国互联网络信息中心（CNNIC）发布的第 57 次《中国互联网络发展状况统计报告》摘要，截至 2025 年 12 月，我国网民规模为 11.25 亿，手机网民规模为 11.21 亿，网民使用手机上网的比例达到 99.6%。同一份报告中，台式电脑、笔记本电脑和平板电脑的使用比例分别为 32.5%、31.2% 和 31.6%。这些设备比例可以多选，并不代表三类设备加起来只能占 100%。
这组数据说明，国内 Web 产品应当以移动端为优先入口，但不能因此只测试手机。移动端要关注触摸、视口、软键盘、网络切换和权限；桌面端仍然承担着办公、政务、教育和复杂生产力场景，宽屏布局、鼠标操作、文件上传和企业内网兼容性同样重要。
浏览器份额呈现平台差异
StatCounter 中国浏览器统计的数据是基于网页访问流量的估算，不等同于浏览器安装量或独立用户数，而且会随着统计月份和样本变化。以 2026 年 7 月的所有平台、桌面端和移动端数据为例：
| 平台 | 主要浏览器及份额 |
|---|---|
| 所有平台 | Chrome 51.59%、Edge 16.36%、Safari 14.44%、360 安全浏览器 4.88%、UC 浏览器 4.85%、QQ 浏览器 3.69% |
| 桌面端 | Chrome 48.16%、Edge 28.81%、360 安全浏览器 10.08%、Firefox 4.65%、QQ 浏览器 3.46%、Safari 3.13% |
| 移动端 | Chrome 56.13%、Safari 24.28%、UC 浏览器 9.61%、Edge 4.57%、QQ 浏览器 3.99% |
从这个分布可以得到几个对兼容性有直接影响的结论：
- 桌面端不能只看 Chrome。 Chrome 和 Edge 占据主要流量，但 360 安全浏览器仍有明显份额。国内桌面用户还可能因为单位软件、网银、政务系统或预装策略使用特定浏览器。
- 移动端的 Safari 和国产浏览器更值得单独关注。 iOS Safari 的布局、权限和媒体能力不能用桌面 Chrome 的测试结果替代；Android 用户还会遇到系统浏览器、厂商浏览器以及应用内 WebView。
- 品牌并不等于内核。 360 安全浏览器官方帮助中同时介绍了 Chromium 极速模式和 Trident 兼容模式；QQ 浏览器的官方说明也曾采用 Chromium 与 IE 双核方案。同一个品牌、同一台电脑，可能因为网址规则或用户设置选择不同渲染内核。
- 浏览器外壳之外还有大量 WebView。 用户可能是在微信、QQ、企业办公软件或其他 App 中打开页面。此时页面的 User-Agent、Cookie、返回行为、文件选择、分享能力和可用 API，都可能与独立浏览器不同。
因此，国内项目的测试对象不能简单写成“Chrome、Firefox、Safari 三大浏览器”。更接近实际的测试矩阵通常包括：
- Windows 上的 Chrome、Edge、360 极速模式；
- 有存量系统要求时，360/QQ 兼容模式或 Edge IE 模式；
- iPhone 上的 Safari，以及主要 App 内的 WKWebView；
- Android Chrome、厂商浏览器和目标 App 内的 WebView；
- 访问统计中占比较高的 UC、QQ、华为、小米等浏览器。
WebView 和老系统要单独验证
浏览器兼容性矩阵实际上有两个维度：一个是浏览器或渲染内核，另一个是宿主环境。用户在微信、QQ、企业办公软件或其他 App 中打开链接时，页面运行在 App 提供的 WebView 中，并不等同于用户单独打开 Chrome 或 Safari。
在 iOS 上，需要关注 Safari 与 WKWebView 的差异；在 Android 上，系统版本、系统 WebView 版本、厂商定制和 App 自带内核可能同时影响结果。Android 7 只是操作系统版本，不能直接代表唯一的 WebView 版本；同一个 Android 版本在不同设备上，实际使用的 Chromium/WebView 版本可能并不相同。微信等 App 还可能根据平台和版本使用不同的 WebView 实现，因此微信内打开页面时，至少应该分别验证 iOS 和 Android，而不是只测试一种手机。
如果用户群体偏老年，设备更换、系统升级和应用更新的周期可能较长，低版本浏览器和旧 WebView 在真实流量中的存续时间会比预期更久。这里不应该简单假设“老年用户都使用旧设备”，而应结合访问统计、客服反馈和业务数据确认。但实际项目不能只按市场份额做决定：少量用户如果无法登录、阅读或完成核心操作，仍然是兼容性问题。
我在 2026 年仍然收到过 iOS 13 和 Android 7 用户反馈页面不支持的情况。这个反馈并不意味着所有 iOS 13 或 Android 7 设备都必然无法访问，而是提醒我们不要用“系统版本低”一句话结束排查。至少需要记录下面的信息：
- 操作系统和具体设备型号；
- 独立浏览器还是微信等 App 内打开；
- 浏览器、App 版本以及 Android WebView/内核版本；
- User-Agent 和实际失败的功能；
- 是页面白屏、脚本报错、布局错位，还是某个 API 不可用。
老系统和 WebView 中比较容易出现的失败方式包括：
- JavaScript 中包含未转换的新语法，导致脚本还没执行就发生解析错误；
- CSS 新属性被忽略，或者新布局没有基础回退，造成页面不可读；
- 剪贴板、文件选择、相机、麦克风、支付、分享等能力受 WebView 权限或 App 容器限制；
- 页面依赖
window.open、下载、返回按钮或历史记录，但这些行为被宿主 App 接管； - 软键盘、刘海屏、状态栏和返回手势导致视口高度、固定定位或表单布局异常。
因此，对这类用户更实际的做法是分层支持：
- 核心层：使用语义 HTML 和成熟 CSS，保证正文、导航、表单和错误提示可用；
- 兼容层：转换必要的 JavaScript 语法，为关键 API 提供降级路径，避免旧环境因为一个增强功能整体白屏；
- 增强层：动画、模糊、复杂手势、复制、分享等能力在不支持时可以隐藏或改为手动操作。
特性检测仍然比 User-Agent 分支更可靠，但 User-Agent 和 WebView 版本日志对于定位线上问题很有价值。可以用它们记录问题和选择测试路径，但不应该仅凭 iOS 13 或 Android 7 就武断地阻止用户访问。
兼容性目标要区分业务类型
对于普通内容、营销和工具类网站，可以将现代 Chromium、Safari 和主流 Android 环境作为 P0，国产浏览器和常见 WebView 作为 P1；如果老年用户或旧设备在访问统计中占比明显，则应把对应的 iOS 13、Android 7、微信 WebView 等环境提升到 P0 或 P1。视觉效果可以降级，但页面阅读、导航、登录或核心操作不能失效。
对于政企、银行、学校和大型企业内部系统，兼容模式可能仍然是实际需求。这时不能只在现代浏览器中验证页面，还要明确以下问题：
- 用户是否真的需要 Trident、ActiveX 或旧版文档模式？
- 兼容模式运行在哪些 Windows 版本和浏览器版本上？
- 页面是否可以迁移到现代 Chromium，还是只能维护一条遗留路径？
- 新旧两套页面是否需要分开构建和发布？
IE 桌面浏览器已经退出历史舞台，并不意味着所有依赖旧内核的业务系统会立即消失。与其笼统地承诺“支持 IE”，不如把具体的浏览器、兼容模式、操作系统和业务流程写入支持矩阵，并为它们准备独立的回归测试。
一次兼容性问题的处理流程
遇到“某个浏览器有问题”时，我会按下面的顺序处理：
1. 先确认是否能稳定复现
记录浏览器、版本、操作系统、设备、网络和复现步骤。尤其是移动端问题，不能只写一句“手机上不行”，因为 Safari、应用内 WebView 和 Android 浏览器的行为可能完全不同。
2. 定位问题属于哪一层
确认是语法不支持、默认样式不同、布局算法差异、Web API 不可用，还是性能和权限问题。不同层的问题，解决方式也不同：
- CSS 属性不支持：增加回退或使用
@supports； - API 不支持：特性检测并提供备用路径；
- 默认样式不同：明确重置，并避免依赖未定义的默认行为；
- 性能不足：减少脚本、图片和动画，而不是只增加 polyfill；
- 浏览器缺陷：缩小复现范围，增加针对性的 workaround，并记录移除条件。
3. 判断它是不是 P0 问题
如果只是圆角、模糊或动画缺失，通常不应该为了它牺牲整个页面的包体积。如果是按钮无法点击、文章无法阅读或表单无法提交，就应该提高优先级。
4. 在生产构建和真实设备上验证
开发服务器能够运行，不代表生产构建后的代码也能运行。至少应该检查：
pnpm run check
pnpm run build然后在目标浏览器中验证构建产物。开发者工具的设备模拟可以帮助检查宽度和触摸事件，但不能完全替代真实的 iPhone、Android 设备以及实际的应用内 WebView。
一份面向国内用户的发布清单
在发布一个依赖新浏览器能力的改动前，可以快速检查：
- 是否明确了受影响的用户和支持范围？
- 不支持该能力时，核心内容是否仍然可用？
- 是否使用了特性检测，而不是 User-Agent 判断？
- CSS 是否有合理的基础样式或回退值？
- 是否检查了窄屏、横屏、缩放和键盘操作？
- 如果用户偏老年，是否验证了低版本设备和较大的文字、点击区域？
- 是否分别验证了微信等 App 内的 iOS WKWebView 和 Android WebView？
- 如果线上仍有旧设备，是否在 iOS 13、Android 7 等真实环境中复现过？
- 是否在 Chromium、Firefox、Safari 中至少各验证了一次？
- 是否在生产构建产物上验证，而不只是开发环境？
- 如果选择不支持某个浏览器，是否把原因写进项目文档？
总结
浏览器兼容性不是一场追求像素完全一致的竞赛，而是一次产品边界和技术成本之间的决策。先用数据和业务定义支持矩阵，再用语义 HTML、渐进增强、特性检测和真实设备测试守住核心体验。
对于内容型站点，最重要的是让文章可读、链接可达、页面可操作；复制、搜索、进度条和装饰效果都可以在能力不足时退化。明确地接受合理降级，往往比为了支持极少数环境而引入复杂的兼容层，更符合实际情况。
相关工具和资料：
- Can I Use：查询 Web 平台特性的浏览器支持情况；
- MDN：Web 浏览器兼容性：了解兼容性测试和浏览器差异；
- MDN：特性查询
@supports：为 CSS 渐进增强提供条件判断；