如果一个网站的新功能能被98%的浏览器访客支持，大多数产品经理会毫不犹豫地拍板上线。但98%的另一面，是被落下的2%——换算到全球网民尺度，这个2%背后是上亿人打不开页面。开发者Hugo最近做了一件更扎心的事：他没有停在“98%听起来很安全”这句话上，而是把自己客户网站过去一年的真实访客数据拉出来，对着一项被官方标注“广泛可用”的CSS新特性，数了一遍浏览器版本。结果只有约七成访客的浏览器支持这个功能，不是官方口径里的95%以上，更不是外界以为的98%。
“广泛可用”是怎么认定的
这项特性是CSS嵌套（Nesting）。Chrome自112版本、Firefox自117版本、Safari自17.2版本起才开始支持，此前版本一律不支持。2023年8月，它被Web标准的Baseline机制标记为“Newly available”（刚获得核心浏览器支持）；MDN文档从2023年12月起，把它进一步标注为“Widely available”（广泛可用）——这也是前端圈普遍认为“可以直接写原生CSS嵌套、不用再等Sass”的起点。
Baseline的“广泛可用”门槛不是拍脑袋定的：官方标准要求核心浏览器稳定支持满30个月，制定门槛时参考的全球支持率在95%左右——多数特性走到这一步时，实际全球支持率早就冲到98%以上。这是几乎所有前端工程师做技术选型时默认信任的数字。
95%到70%，差在哪
Hugo没有止步于相信这套官方口径，他去查了自己客户网站过去一年的真实访客浏览器分布——结果只有约七成访客的浏览器支持CSS嵌套，三成被挡在门外。同一个“广泛可用”的功能，全球统计和具体网站实测之间能差出近三十个百分点。
这不是Baseline统计造假，而是它天生量的是“全球平均”，不是“你的用户”。真正拉开差距的是几个具体变量：老旧iOS/Safari设备的换机周期比Chrome、Firefox的自动更新慢得多；企业IT出于安全和兼容性考虑，常年锁死内网浏览器版本不让员工升级；不同地域、不同行业的访客群体，浏览器版本分布本来就和“全球平均”对不上号。一个ToC消费类应用的访客确实可能接近98%，但一个ToB、政企或老旧设备占比高的产品，实测支持率掉到七成一点都不奇怪。
地图不是疆域，统计不是你的用户
孟子那句“尽信书，不如无书”用在这儿正合适——Can I Use和Baseline是权威地图，画的是全球平均海拔，不是你脚下这块地的实际坡度。
直接用，还是绕一圈
前端圈子里对CSS嵌套该不该直接上线一直有分歧。一派认为Chrome、Firefox、新版Safari都已稳定支持，直接写原生嵌套语法没问题，该淘汰Sass编译管线了。另一派更谨慎，坚持给老旧Safari、iOS Safari和被锁定的企业浏览器留后路，用@supports (selector(&))做特性检测，判断不支持就回退到扁平写法；也有人干脆继续用Sass/PostCSS编译，把新语法降级成兼容写法，牺牲一点开发体验换稳妥。
- 建议.能加一层
@supports特性检测再上线，就不要为了省事直接把原生语法甩给所有访客——渐进增强的维护成本，远低于一部分用户打开页面发现样式全乱的代价。
Hugo的判断很直接：如果一个新特性没法优雅降级，那它就没资格叫“广泛支持”——就算全球数字再漂亮，对那部分打不开页面的人来说，支持率是零，不是98%。这话听着极端，但逻辑没毛病：食物中毒概率2%的餐厅，没人会说它食品安全；工资98%准时发的公司，也没人愿意留下来。基本盘的容错率，从来不是用平均数算的。
真正该改的不是要不要相信Can I Use或Baseline，而是别让它替代自己的数据。这两套统计给的是行业基线，不是产品决策的终点。真正靠谱的做法，是把自己网站过去一段时间的真实访客浏览器分布拉出来看一眼，再决定要不要把降级方案省掉——这件事成本不高，省下的可能是实打实的转化率，和一部分永远不会抱怨、只会默默关掉页面走人的用户。