為什麼 98% 的支援度對於穩健工程而言並不充足

98% 的成功率掩蓋了關鍵差距

A 98% 的成功率聽起來很高，但在失敗會導致嚴重後果的場景中——例如食品安全、薪資發放或無障礙設計——這意味著頻繁且無法接受的事故。對於一家餐廳來說，98% 的無食物中毒服務意味著每個月大約會有一位顧客生病。對於雇主來說，漏發 2% 的薪水是一項重大的信任違約。

當利害關係重大時，百分比會產生誤導

當失敗的成本很高時，失敗的絕對數量比百分比更重要。一個對全球 98% 的人口都能運作的網站，仍然排除了大約 1.5 億名用戶。如果這些用戶屬於特定的目標受眾，其影響可能更大。作者本人在巢狀 CSS 方面的經驗說明了這一點：雖然該功能在通用統計數據中被「廣泛支援」，但該網站僅有約 70% 的訪客可以使用它，導致 30% 的受眾被困住。

邊緣案例需要優雅降級

穩健工程並非關於「大多數用戶都能正確執行」；而是關於如何優雅地處理邊緣案例。如果一個新的瀏覽器功能無法降級，那麼缺乏支援的 2% 用戶將會遇到功能失效的體驗，這與「廣泛支援」的說法相矛盾。漸進式增強（Progressive enhancement）——透過 @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% 的準確度，但那仍然意味著每頁有五個錯誤——這證明了高百分比仍可能產生明顯的失敗。"

當部分信用可以接受時

並非所有的失敗都是二元對立的。在網頁開發中，一個部分功能化的功能可能仍然能提供價值，不像食品安全或薪資發放那樣任何失敗都是不可接受的的。

開發者的實務指南

1. 識別失敗成本 – 確定 2% 的失敗率是否可以接受（例如，美觀的 UI 差異）或災難性的（例如，安全、健康、品質、支付）。
2. 衡量你的實際受眾