为什么 98% 的支持率对于稳健工程来说是不够的

98% 的成功率掩盖了关键缺陷

98% 的成功率听起来很高，但在失败后果严重的场景中——如食品安全、工资发放或无障碍设计——它意味着频繁且不可接受的事故。对于一家餐厅来说，98% 的无食物中毒服务率意味着大约每月会有一名顾客生病。对于雇主来说，2% 的漏发工资率是一次重大的信任违约。

当风险很高时，百分比具有误导性

当失败的成本很高时，失败的绝对数量比百分比更重要。一个对全球 98% 的人口都能正常工作的网站仍然排除了大约 1.5 亿用户。如果这些用户属于特定的目标受众，其影响可能会更大。作者本人在嵌套 CSS 方面的经验说明了这一点：尽管该功能在通用统计数据中被“广泛支持”，但该网站只有约 70% 的访客可以使用它，导致 30% 的受众处于困境。

边缘情况需要优雅降级

稳健工程的核心不在于“大多数用户都能正确使用”；而在于如何优雅地处理边缘情况。如果一个新的浏览器功能无法降级，那么那 2% 缺乏支持的用户就会遇到功能损坏的体验，这与“广泛支持”的说法相矛盾。渐进式增强——通过 @supports 或 JavaScript 功能检测来检查功能支持情况——允许开发者为所有用户提供功能性基准，同时在可能的情况下提供高级功能。

社区对 98% 阈值的看法

wccrawford: "如果你的业务计划要求你利用超过 98% 的市场，那么它已经失败了。权衡在于代码复杂性与市场规模，每家公司必须自行决定。"

nemo1618: "从圣诞树上移除超过 99% 的针，仍然会留下明显的混乱；当你接近 100% 时，剩下的 1% 会更加显眼。"

MatekCopatek: "利润动机通常驱动了对 98% 支持率的接受。例如，票务服务可能会忽略 2% 的失败率，因为修复它所花费的成本比损失的销售额还要高。"

phailhaus: "百分比可能具有欺骗性；将成功率表示为概率（1/50 对比 1/100）可以凸显从 98% 提升到 99% 的真实影响。"

onion2k: "如果一个功能无法优雅降级，那么它就不是真正的‘广泛支持’。使用带有 @supports 或功能检测 JavaScript 的渐进式增强；额外的工作量是极小的。"

collinmanderson: "美国和英国政府网站官方仅支持 98% 的浏览器。在一个月内有 16.6 亿次会话，2% 相当于大约 3300 万次会话——这绝非微不足道。"

compiler‑guy: "早期的 OCR 软件声称 99% 的准确率，但那仍然意味着每页有五个错误——这证明了高百分比仍然可能产生明显的失败。"

当部分信用可以接受时

并非所有失败都是二元的。在 Web 开发中，一个部分功能化的功能仍然可以提供价值，这与食品安全或工资发放不同，在那些场景中任何失败都是不可接受的的。

开发者实用指南

1. 识别失败成本 – 确定 2% 的失败率是否可以接受（例如，外观 UI 差异）还是灾难性的（例如，安全、健康、支付）。
2. 测量你的实际受众 – 通用市场份额统计数据可能会夸大对你特定用户群体的支持程度。
3. 实施渐进式增强 – 为所有浏览器提供基准体验，支持功能检测后叠加高级功能。
4. 监控边缘情况指标 – 追踪被排除的 2% 的体验，以了解现实世界的影响并优先处理修复工作。
5. 用概率而非百分比进行沟通 – 将可靠性表述为“1/50 的用户可能会遇到问题”以传达少数派的群体规模的重要性。

结论

98% 的成功率是一个方便的简写，但它在关键领域往往掩盖了不可接受的失败。稳健工程要求我们超越表面的百分比，衡量对实际受众的影响，并设计能够优雅地处理剩余边缘情况的系统的。