跳轉到主要內容
類別：定律
類型：軟體效能與複雜度啟發式
來源：通常歸於電腦科學家尼克勞斯・沃斯（1990 年代中期）
別名：軟體膨脹原則
快速回答 — 沃斯定律（Wirth’s Law）指出：軟體變慢的速度，常快於硬體變快。它揭示的核心不是晶片不夠快，而是複雜度治理失敗。有效做法是把延遲預算、記憶體預算與依賴上限設為硬性產品要求。

​
什麼是沃斯定律？

沃斯定律（Wirth’s Law）是一條工程警示：硬體進步不會自動轉化為使用者體感速度，因為軟體層的抽象與功能膨脹可能更快吃掉效能紅利。這也是為何新裝置不一定更順暢。
效能紅利不會自動抵達使用者；要嘛被工程化兌現，要嘛被複雜度吞噬。
它可與 摩爾定律（硬體能力成長）、布魯克斯定律（協作規模帶來協調成本）和 康威定律（組織結構映射系統結構）併讀，也與 霍夫施塔特定律 互補：複雜度成本往往被低估。

​
沃斯定律的三層理解

  • 入門：換更快硬體，不代表軟體體感必然更快。
  • 實踐者：建立明確效能預算，超預算功能必須先證明價值。
  • 進階：把架構、激勵與發布門檻對齊，讓複雜度增速低於容量增速。

​
起源

此說法通常歸於電腦科學家 尼克勞斯・沃斯，他長期強調精簡軟體與語言／工具設計紀律。1990 年代硬體快速進步時，業界卻反覆觀察到日常軟體體感未同步提升，主因正是抽象層與功能層持續疊加。 這一定律歷久不衰，是因為它準確描述了組織模式：團隊通常為可見功能被獎勵，而效能成本被外部化給使用者與未來維護者。

​
核心要點

沃斯定律本質上是軟體經濟學與治理問題。
1

複雜度會默默消耗容量

每增加一層框架、依賴或整合，都可能在啟動、執行和故障路徑上增加隱性開銷。
2

預設激勵偏向功能堆疊

團隊較易因新增功能被肯定，而較少因維持效能餘裕被肯定。
3

效能負債具複利效應

每次小幅回退長期累積，會演變成明顯延遲和基礎設施成本壓力。
4

預算機制讓取捨可執行

將效能預算寫入發版標準，速度才會成為可審計的決策條件。

​
應用場景

把效能治理從事後救火前移到設計與評審流程。

Web 產品

在 CI 持續監控包體與互動延遲預算，超閾值即阻擋合併。

行動應用

以中階裝置的冷啟動與記憶體壓力作為主要驗收基準，不只看旗艦機。

後端服務

控制依賴擴張並監測尾延遲，避免版本演進中可靠性逐步下滑。

工程管理

把效能回退納入路線圖成本，終止「硬體會兜底」的默認假設。

​
經典案例

公開 Web 長期遙測顯示，平均頁面複雜度與資源體積顯著增長，JavaScript 與媒體載荷提高了傳輸與執行成本。在許多團隊中，這些增量抵消了部分硬體與網路進步帶來的紅利，尤其在中階手機更明顯。實務常用可量化指標是 Core Web Vitals（如 LCP、INP）；若缺乏預算門檻，功能密集發布後常出現回退。以沃斯定律解讀，重點很直接：效能不是自然產物，而是治理結果。

​
邊界與失效場景

沃斯定律描述的是常見趨勢，並非反對所有抽象化。 邊界一：工具鏈進步可扭轉趨勢
編譯器最佳化、執行時改進與架構簡化都能有效回收效能。 邊界二：部分效能成本具正當價值
安全性、可及性與正確性提升，可能提高計算開銷但改善整體品質。 常見誤用：引用此定律全面否定現代化改造，而不做價值與延遲的明確權衡。

​
常見誤區

正確理解可避免「盲目追新」與「盲目守舊」兩端擺盪。
事實：問題不在框架存在，而在是否持續度量並治理其開銷。
事實：硬體進步仍重要，只是若治理不足，增益會被軟體側吃掉。
事實：長期效能表現多在早期架構與預算決策時就已被決定。

​
相關概念

這些概念可協助把沃斯定律落地為工程制度。

摩爾定律

硬體能力成長提供機會，但不保證使用者體感同步提升。

康威定律

組織溝通結構會塑造系統結構，也會塑造效能負債形態。

布魯克斯定律

協調成本上升會推高複雜度，進一步拖慢品質與交付效率。

​
一句話總結

硬體給的是效能預算，軟體治理決定這份預算是回到使用者，還是被複雜度吃掉。