98% 支持率，还得留扇门

Hugo Barrera 的 "98% isn't 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 用户"，而是那个网站真实的流量。

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

CSS 嵌套是个不错的试金石

CSS 嵌套是个好例子，因为它不是噱头。MDN 的指南把它描述为浏览器原生解析的 CSS，不是预编译的 Sass，并提到它能让样式表更易读、更模块化，有时还能更小。Chrome 的开发者文档也从代码组织、减少重复、便于重构的角度给出了类似理由。

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

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

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

Baseline 不是许可证

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

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

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

社区的反应是分裂的

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

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

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

一份更好的采用检查清单

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

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

我的结论

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

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