# 98% 支持率，还得留扇门

**Summary:** Hugo Barrera 关于 98% 支持率的文章提醒我们：浏览器兼容性的平均值不等于受众保证。我认为采用现代 CSS 需要结合数据分析、降级方案和优雅退化。

- Canonical: https://markhuang.ai/zh/news/browser-support-needs-fallbacks
- Language: zh-CN
- Author: [Mark Huang](https://markhuang.ai/about)
- Published: 2026-07-07
- Section: News
- Tags: Web 开发, CSS, 无障碍, 前端, 渐进增强
- Source: [WhyNotHugo](https://whynothugo.nl/journal/2026/07/03/98-isnt-very-much/)
- License: https://creativecommons.org/licenses/by-nc/4.0/

---

![漫画中一个网站门口欢迎大多数访客，而几个人被挡在一道透明的兼容性屏障后面](https://cdn.markhuang.ai/news/browser-support-needs-fallbacks/hero.webp)

*Hugo Barrera 这篇文章最扎心的一点是：一个百分比看起来可以非常漂亮，但背后是被挡在门外的真实用户。*

Hugo Barrera 的 ["98% isn't very much"](https://whynothugo.nl/journal/2026/07/03/98-isnt-very-much/) 是一篇篇幅不长的 Web 开发文章，但观点很犀利：一个听起来很漂亮的兼容性数字，一旦放到基本访问层面，承诺其实很弱。他并不是说现代浏览器特性不好，而是说一个对绝大多数人都能用的网站，仍然可能把数量惊人的用户拒之门外，而且全球支持率数据未必能反映某个具体网站的实际受众。

我觉得这才是 2026 年讨论浏览器兼容性的正确姿势。我想要现代 Web 平台带来的能力，但也希望团队别再觉得"广泛支持"就等于"对我的用户没问题"。到底要不要用，得看影响范围、受众数据，以及不支持的浏览器能不能走一条体面的降级路径，而不是直接给用户一个坏掉的页面。

## 答案快照

| 问题      | 我的看法                                                                   |
| ------- | ---------------------------------------------------------------------- |
| 发生了什么？  | 2026 年 7 月 3 日，WhyNotHugo 发了一篇文章，认为当缺失的 2% 意味着真实用户无法使用网站时，98% 的支持率并不够。 |
| 为什么重要   | 浏览器支持率这个数字压缩了太多信息：全球使用率、核心浏览器支持、本地受众构成、降级质量，其实是不同的问题。                  |
| 谁受益？    | 使用老旧、受管、小众、移动端、辅助技术或受限浏览环境的用户，以及想用现代 CSS 又不想踩到意外回归的前端团队。               |
| 我的核心观点  | 只有在不支持的路径可以接受时，新的 Web 特性才算安全。如果失败会破坏核心体验，98% 就不是终点。                    |
| 我没有在说什么 | 我不是在说每个网站都得永远支持每一个旧浏览器，也不是在说 CSS 嵌套不好。我只是在说，支持标准取决于什么会坏掉。              |

## 这个数字承担了太多

Barrera 最有力的一招，是把锦上添花和基本保障分开看。98% 的成功率，放在一项高难度成就上听起来很棒；但如果期待的是基本可靠性，这个数字的味道就完全不一样了。放到 Web 上，缺失的百分比不是抽象的余数。原文提到，一个对 98% 人口有效的特性，仍然可能把大约 1.5 亿人排除在外。

更实际的警告在于："98% 的人口"未必等于"98% 的网站实际受众"。Barrera 说他在考虑是否移除 SCSS 管道时，查了一个客户的浏览器分布，结果发现过去一年里，访问的浏览器中只有大约 70% 支持相关的新 CSS 特性。这一点最难一带而过。那个决策面对的不是一个抽象的"通用 Web 用户"，而是那个网站真实的流量。

这就是为什么我不太接受只抛一个百分比就下结论的兼容性讨论。数字有用，但数字不是决策。决策要看的是：这个特性是装饰性的、渐进增强的、可恢复的，还是承载核心功能的。

![漫画中一个开发者在研究分组的浏览器受众，发现其中一个群体的兼容性拼图缺了几块](https://cdn.markhuang.ai/news/browser-support-needs-fallbacks/why-it-matters.webp)

*全球平均值可以掩盖真正访问你网站的那群人。本地分布才是经常更关键的那个数字。*

## CSS 嵌套是个不错的试金石

CSS 嵌套是个好例子，因为它不是噱头。[MDN 的指南](https://developer.mozilla.org/en-US/docs/Web/CSS/Guides/Nesting/Using)把它描述为浏览器原生解析的 CSS，不是预编译的 Sass，并提到它能让样式表更易读、更模块化，有时还能更小。[Chrome 的开发者文档](https://developer.chrome.com/docs/css-ui/css-nesting)也从代码组织、减少重复、便于重构的角度给出了类似理由。

所以支持采用的理由是实打实的。原生嵌套为部分网站去掉了一个构建步骤依赖，给作者一种熟悉的方式来组织相关选择器，也已经成为现代平台讨论的一部分。[Baseline](https://web.dev/baseline) 还给开发者提供了一套讨论支持情况的共同语言：newly available 表示所有核心浏览器都已支持，widely available 表示距离那个互操作日期已经过了 30 个月。

但细节仍然重要。[Sass 团队 2023 年的文章](https://sass-lang.com/blog/sass-and-native-nesting/)解释过，原生嵌套和 Sass 嵌套并不完全一样，`:is()` 的特异性计算和选择器后缀行为都有差异。Sass 团队表示，在原生嵌套的全球浏览器市场份额达到 98% 之前，不会修改现有合法的 Sass 输出来生成浏览器不兼容的 CSS。这种谨慎不是怀旧，而是来自一群深知生产环境里有多少 CSS 在跑的人的兼容纪律。

根据我查看的 [Can I Use CSS Nesting 页面](https://caniuse.com/css-nesting)，该特性的全球使用率支持（合并完全和部分支持）为 90.81%，使用率数据基于 2026 年 6 月的 StatCounter 统计。这个数字高到值得关注，也低到足以证明 Barrera 的观点："现代"这个标签并不能告诉我，一个网站对不支持浏览器的降级路径是否可接受。

## Baseline 不是许可证

我喜欢 Baseline，因为它用一套共同术语替代了凭感觉下结论的做法，让平台讨论、代码检查和教学都更容易。问题出在团队把这套术语当成一张"能/不能"的许可证来用。

[ESLint CSS `use-baseline` 规则文档](https://github.com/eslint/css/blob/main/docs/rules/use-baseline.md)在这点上很克制。它说 Baseline 有助于互操作性，但测试仍然不可省略，尤其是当受众使用核心浏览器之外的浏览器时。它还提到无障碍测试仍然必须做，因为 Baseline 不追踪辅助技术的支持情况，同时也为 `@supports`、降级方案和渐进增强留足了空间。

这才是我信任的 Baseline 用法。它是工程决策的好输入，但不是决策本身。一个特性可以是 Baseline，但仍然是公共表单、结账流程、浏览器被锁定的企业内部应用，或者受众集中在老旧移动设备上的网站的错误选择。

> **Info:**
>
> 我的经验法则很简单：失败后果越严重，支持标准就得越高。如果不支持的浏览器拿到的仍然是一个可读的页面、一条能走通的路，那我就可以跑得更快。如果它们拿到的是一个坏掉的核心体验，那百分比就得高得多才行。

![漫画中一个维护者在现代 CSS 模块和降级坡道之间权衡，旁边的访客在等一条能用的路](https://cdn.markhuang.ai/news/browser-support-needs-fallbacks/tradeoff.webp)

*取舍不是"旧 Web"对"新 Web"，而是开发者的便利和把用户挡在基本功能之外的代价之间的权衡。*

## 社区的反应是分裂的

围绕原生 CSS 嵌套的开发者讨论，正好体现了这种真实的分裂。在一个关于[原生 CSS 嵌套是否安全](https://www.reddit.com/r/webdev/comments/1am0fgk/is_it_safe_to_use_native_css_nesting/)的 Reddit webdev 帖子里，有人直接表达担忧：如果嵌套是样式表的基础结构，不支持的浏览器丢掉的可能远不止一点视觉优化。另一些评论者则觉得，只要支持范围限定在最近版本的 Chrome、Edge、Firefox 和 Safari，就可以放心往前走。

这种分裂并不离谱，它取决于受众。一个浏览器策略很窄的私有项目，能承受的风险和一个公共信息网站、学校系统、政府相关服务，或者用户在使用受管硬件的产品完全不同。问题在于假装存在一个放之四海而皆准的门槛。

持怀疑态度的一方也有可维护性上的论据。Piccalilli 的 ["CSS nesting: use with caution"](https://piccalil.li/blog/css-nesting-use-with-caution/) 认为嵌套更多是在解决开发者的问题，而不是终端用户的问题，提醒注意特异性的坑，并建议如果要用嵌套就保持浅层。我并不完全认同那种最极端的批评，但我觉得这种压力是有用的。一个能改善编写体验的特性，如果用得不加思考，仍然可能让运行时兼容性和代码可读性变差。

## 一份更好的采用检查清单

| 问题            | 我会怎么查                                               |
| ------------- | --------------------------------------------------- |
| 这是锦上添花还是基础设施？ | 如果特性只是改进布局细节，降级可以很简单。如果它控制的是导航、表单、支付、阅读或认证，标准就得高得多。 |
| 没有支持时会怎样？     | 直接测试不支持的路径。用户看到的是可用内容、缩减后的布局，还是一个坏掉的界面？             |
| 真实流量怎么说？      | 看受众实际的浏览器和设备数据，不要只看全球兼容性表。                          |
| 特性可以隔离吗？      | 用 `@supports`、构建输出、渐进增强或更简洁的 CSS，让不支持的浏览器绕开脆弱的路径。   |
| 回归怎么暴露？       | 把兼容性检查、数据分析、支持报告和无障碍测试贴近发布流程。                       |

这份清单不够光鲜，但它正是"现代化代码库"和"悄悄放弃一部分受众"之间的区别。目标不是冻结 Web，而是让每一次特性采用都看得清楚：什么变好了，什么会坏，谁受影响，团队怎么知道。

![漫画中工程师把功能模块依次经过仅支持、降级、数据分析和无障碍几道关卡，用户才拿到可用的页面](https://cdn.markhuang.ai/news/browser-support-needs-fallbacks/workflow-risk.webp)

*操作层面的答案是检测、降级、数据分析和无障碍审查，而不是把一个百分比直接搬进发布决策。*

## 我的结论

Barrera 这篇文章之所以有效，是因为它戳破了一个偷懒的捷径，又没有变成反对进步的怀旧论调。我希望团队在能让产品变得更好的时候，去用原生 CSS 嵌套、容器查询、`:has()` 以及平台提供的其他能力。但我也希望他们同时问一问：那些不在顺利路径上的用户，会遭遇什么。

对我来说，98% 本身谈不上"好"或"不好"。它是一个提示，让你去问更尖锐的问题：对这个网站来说，剩下的 2% 真的很少吗？受众分布清楚吗？缺失的支持是不是恰好集中在产品声称要服务的人群里？页面能优雅降级吗？如果这些问题的答案站不住，那"广泛支持"就不够用——它不过是一种更好听的把人留在门外的说法。