> ## Documentation Index
> Fetch the complete documentation index at: https://meta.niceshare.site/llms.txt
> Use this file to discover all available pages before exploring further.

# 沃斯定律

> 沃斯定律提醒我们：软件变慢的速度，常快于硬件变快。它要求团队把性能预算和复杂度控制纳入日常治理，而非事后救火。

<Info>
  **类别**：定律<br />
  **类型**：软件性能与复杂度启发式<br />
  **来源**：通常归于计算机科学家尼克劳斯·沃斯（20 世纪 90 年代中期）<br />
  **别名**：软件膨胀原则
</Info>

<Note>
  **快速回答** — **沃斯定律**（Wirth's Law）指出：软件变慢的速度，往往快于硬件变快。它揭示的不是芯片问题，而是治理问题：性能冗余经常被功能堆叠和抽象层吞噬。要破解它，必须把延迟预算、内存预算和复杂度上限变成硬约束。
</Note>

## 什么是沃斯定律？

**沃斯定律**（Wirth's Law）是一条工程警示：硬件进步并不会自动转化为用户体感速度，因为软件复杂度增长可能更快。它解释了为什么设备代际升级后，产品仍可能“更卡”。

> 性能红利不会自动到达用户，它要么被工程化兑现，要么被复杂度消耗。

它可与 [摩尔定律](/zh/laws/moores-law)（硬件能力增长）、[布鲁克斯定律](/zh/laws/brookss-law)（协作规模带来协调开销）和 [康威定律](/zh/laws/conways-law)（组织结构映射到系统结构）联用，也与 [霍夫施塔特定律](/zh/laws/hofstadters-law) 互补：复杂度成本常被低估。

### 沃斯定律的三层理解

* **入门**：换更快硬件，不等于软件一定更快。
* **实践者**：设定可执行的性能预算，超预算功能必须证明收益再上线。
* **进阶**：把架构、团队激励和发布门禁统一到“复杂度增速低于容量增速”这一目标上。

## 起源

该表述通常归于计算机科学家 **尼克劳斯·沃斯**，其长期主张精简软件与语言/工具设计纪律。20 世纪 90 年代硬件能力快速提升时，行业却反复观察到日常软件体感并未同比提升，原因正是抽象层和功能层不断叠加。

这一定律持续流行，是因为它抓住了组织层面的重复模式：团队通常被激励去“交付更多可见功能”，而运行时成本被外部化给用户和未来维护者。

## 核心要点

沃斯定律的核心在于软件经济学，而不只是底层硬件速度。

<Steps>
  <Step title="复杂度会悄悄吞掉容量">
    每增加一层框架、依赖或集成，都可能在启动、内存和故障路径上增加隐性开销。
  </Step>

  <Step title="默认激励偏向功能堆叠">
    团队更容易因“新增了什么”被奖励，而不是因“保持了多快”被奖励。
  </Step>

  <Step title="性能债会复利积累">
    每次发布的小幅回退叠加起来，最终会变成大规模延迟与基础设施成本问题。
  </Step>

  <Step title="预算让权衡变得可执行">
    性能预算把“希望更快”变成可审计的发布条件，逼迫团队做取舍。
  </Step>
</Steps>

## 应用场景

把性能治理从“线上告警后抢修”前移到“设计和评审阶段”。

<CardGroup cols={2}>
  <Card title="Web 产品" icon="globe">
    在 CI 中监控包体与交互延迟预算，超过阈值就阻止合并。
  </Card>

  <Card title="移动应用" icon="mobile-screen-button">
    以中端机冷启动和内存压力为主目标，不只在旗舰机上验证流畅度。
  </Card>

  <Card title="后端服务" icon="server">
    控制依赖蔓延并持续监控尾延迟，防止版本迭代中可靠性被慢慢侵蚀。
  </Card>

  <Card title="工程管理" icon="users-gear">
    把性能回退纳入路线图成本核算，避免“硬件会兜底”的默认借口。
  </Card>
</CardGroup>

## 经典案例

过去十余年的公开 Web 监测数据显示，页面复杂度与资源体积显著上升，JavaScript 包和媒体资源增大，导致传输与执行成本上升。在很多团队中，这部分增长抵消了部分硬件与网络进步带来的红利，尤其影响中端手机用户。常见可量化指标是 Core Web Vitals（如 LCP 与 INP），在功能密集发布后若无预算门禁，常出现明显回退。用沃斯定律解读，结论很直接：性能不是“自然结果”，而是“治理结果”。

## 边界与失效场景

沃斯定律描述高频趋势，但不是反对一切抽象层。

**边界一：工具链进步可反向改善性能**\
编译器、运行时与架构优化可以扭转变慢趋势。

**边界二：某些性能成本有业务价值**\
安全、可访问性和正确性增强，可能增加计算开销但提升整体产品质量。

**常见误用**：拿这一定律否定现代化改造本身，而不是做清晰的“价值-延迟”权衡。

## 常见误区

正确理解有助于避免“盲目追新”和“盲目守旧”两种极端。

<AccordionGroup>
  <Accordion title="误区：它说明所有现代框架都不好">
    **事实**：问题不在框架存在，而在开销是否被持续度量和约束。
  </Accordion>

  <Accordion title="误区：硬件升级已经没有意义">
    **事实**：硬件进步仍重要，但若缺少治理，软件会吞掉增益。
  </Accordion>

  <Accordion title="误区：性能优化只能后期再做">
    **事实**：大部分性能结果在架构和预算决策阶段就已基本确定。
  </Accordion>
</AccordionGroup>

## 相关概念

将这些概念配套使用，能把沃斯定律落实到工程系统里。

<CardGroup cols={3}>
  <Card title="摩尔定律" icon="microchip" href="/zh/laws/moores-law">
    硬件能力增长提供机会，但不保证用户体验同步变快。
  </Card>

  <Card title="康威定律" icon="diagram-project" href="/zh/laws/conways-law">
    组织沟通结构会塑造系统结构，也会塑造性能开销结构。
  </Card>

  <Card title="布鲁克斯定律" icon="people-group" href="/zh/laws/brookss-law">
    协调复杂度上升会拖慢交付质量并放大系统复杂度。
  </Card>
</CardGroup>

## 一句话总结

<Tip>
  硬件给你性能预算，软件治理决定这份预算是给用户，还是被复杂度吃掉。
</Tip>