类别：定律
类型：软件性能与复杂度启发式
来源：通常归于计算机科学家尼克劳斯·沃斯（20 世纪 90 年代中期）
别名：软件膨胀原则
类型：软件性能与复杂度启发式
来源：通常归于计算机科学家尼克劳斯·沃斯（20 世纪 90 年代中期）
别名：软件膨胀原则
快速回答 — 沃斯定律（Wirth’s Law）指出：软件变慢的速度，往往快于硬件变快。它揭示的不是芯片问题，而是治理问题：性能冗余经常被功能堆叠和抽象层吞噬。要破解它，必须把延迟预算、内存预算和复杂度上限变成硬约束。
什么是沃斯定律？
沃斯定律（Wirth’s Law）是一条工程警示：硬件进步并不会自动转化为用户体感速度，因为软件复杂度增长可能更快。它解释了为什么设备代际升级后，产品仍可能“更卡”。性能红利不会自动到达用户，它要么被工程化兑现，要么被复杂度消耗。它可与 摩尔定律（硬件能力增长）、布鲁克斯定律（协作规模带来协调开销）和 康威定律（组织结构映射到系统结构）联用，也与 霍夫施塔特定律 互补：复杂度成本常被低估。
沃斯定律的三层理解
- 入门：换更快硬件，不等于软件一定更快。
- 实践者：设定可执行的性能预算，超预算功能必须证明收益再上线。
- 进阶：把架构、团队激励和发布门禁统一到“复杂度增速低于容量增速”这一目标上。
起源
该表述通常归于计算机科学家 尼克劳斯·沃斯，其长期主张精简软件与语言/工具设计纪律。20 世纪 90 年代硬件能力快速提升时，行业却反复观察到日常软件体感并未同比提升，原因正是抽象层和功能层不断叠加。 这一定律持续流行，是因为它抓住了组织层面的重复模式：团队通常被激励去“交付更多可见功能”，而运行时成本被外部化给用户和未来维护者。核心要点
沃斯定律的核心在于软件经济学，而不只是底层硬件速度。应用场景
把性能治理从“线上告警后抢修”前移到“设计和评审阶段”。Web 产品
在 CI 中监控包体与交互延迟预算，超过阈值就阻止合并。
移动应用
以中端机冷启动和内存压力为主目标，不只在旗舰机上验证流畅度。
后端服务
控制依赖蔓延并持续监控尾延迟，防止版本迭代中可靠性被慢慢侵蚀。
工程管理
把性能回退纳入路线图成本核算，避免“硬件会兜底”的默认借口。
经典案例
过去十余年的公开 Web 监测数据显示，页面复杂度与资源体积显著上升，JavaScript 包和媒体资源增大，导致传输与执行成本上升。在很多团队中，这部分增长抵消了部分硬件与网络进步带来的红利，尤其影响中端手机用户。常见可量化指标是 Core Web Vitals（如 LCP 与 INP），在功能密集发布后若无预算门禁，常出现明显回退。用沃斯定律解读，结论很直接：性能不是“自然结果”，而是“治理结果”。边界与失效场景
沃斯定律描述高频趋势，但不是反对一切抽象层。 边界一：工具链进步可反向改善性能编译器、运行时与架构优化可以扭转变慢趋势。 边界二：某些性能成本有业务价值
安全、可访问性和正确性增强，可能增加计算开销但提升整体产品质量。 常见误用：拿这一定律否定现代化改造本身，而不是做清晰的“价值-延迟”权衡。
常见误区
正确理解有助于避免“盲目追新”和“盲目守旧”两种极端。误区：它说明所有现代框架都不好
误区：它说明所有现代框架都不好
事实：问题不在框架存在，而在开销是否被持续度量和约束。
误区：硬件升级已经没有意义
误区：硬件升级已经没有意义
事实：硬件进步仍重要，但若缺少治理，软件会吞掉增益。
误区：性能优化只能后期再做
误区：性能优化只能后期再做
事实：大部分性能结果在架构和预算决策阶段就已基本确定。
相关概念
将这些概念配套使用，能把沃斯定律落实到工程系统里。摩尔定律
硬件能力增长提供机会，但不保证用户体验同步变快。
康威定律
组织沟通结构会塑造系统结构，也会塑造性能开销结构。
布鲁克斯定律
协调复杂度上升会拖慢交付质量并放大系统复杂度。