海勒姆定律

​

什么是海勒姆定律？

海勒姆定律（Hyrum’s Law）是一条观察：用户足够多时，系统的每一种可观察行为都会变成某人的依赖——无论官方合约是否写明。

只要 API 用户足够多，你在合约里承诺什么并不重要：系统的一切可观察行为，都会被某人依赖。

可以把菜单当成合约，把后厨习惯当成实现：客人可能开始期待从未写进菜单的餐盘尺寸、等待时间和配菜。软件里，排序结果、错误文案、耗时，甚至 bug，都可能变成承重墙。规模一大，“私有”实现就不再私有：消费者集体把整块表面钉死。

​

海勒姆定律的三层理解

• 入门：用户看得见的东西，总会有人拿来搭积木——管你写没写进文档。
• 实践：改库或改 API 之前，先问调用方可能已经依赖了哪些“文档之外”的行为。
• 进阶：按使用熵来设计——减少意外可观察面，用测试发现破坏，并在必须改隐式接口时预留迁移成本。

​

起源

Hyrum Wright 在 Google 做大规模库与基础设施变更时提炼出这一观察：即便对核心 C++ 库做“看不见”的微调，也会弄坏远处那些依赖偶然行为的系统。他把极端形式称为隐式接口定律——消费者足够多时，实质上不存在私有实现，维护者往往需要逐 bug 兼容。 同事 Titus Winters 将其命名为 Hyrum’s Law，并在 Google 内部推广。2020 年 O’Reilly 出版的《Software Engineering at Google》（Winters、Wright、Manshreck）把它当作长生命周期代码的核心约束：讨论变更必须正视海勒姆定律，就像讨论效率必须正视熵——可以缓解，无法消灭。 Wright 的公开站点（hyrumslaw.com）固定了经典表述，并把它与 Joel Spolsky 的泄漏抽象定律（Law of Leaky Abstractions）相连：消费者终究会注意到、并依赖从抽象中漏出来的细节。

​

核心要点

海勒姆定律与其说是道德戒律，不如说是对大规模用户如何冻结可见行为的预测。

​

应用场景

只要某样东西共享得足够广，“没人会依赖那个”就往往是一厢情愿——这时就用海勒姆定律。

​

经典案例

Python 字典排序展示了海勒姆定律如何把实现细节变成语言承诺。在 CPython 3.6（2016）中，紧凑字典重设计让插入顺序得以保留，但这只是实现细节——有用且可见，却不是对所有 Python 实现的语言保证。调用方仍开始在实践中假设该顺序。 到 2017 年 12 月 15 日，经 python-dev 讨论，Guido van Rossum 裁定：“Make it so. ‘Dict keeps insertion order’ is the ruling.” Python 3.7（2018 年 6 月 27 日发布）随后把插入顺序保留宣布为语言规范的正式部分，合规实现必须遵守。项目选择追认已被广泛观察的行为，而不是故意打乱顺序并弄坏已适应的生态。教训很尖锐：足够多用户看得见某种行为后，“从未承诺”是弱辩护；要么吸收成合约，要么支付强制迁移。边界同样尖锐：追认只是一种策略——当偶然行为有害或锁死更好设计时，并不总是正确选择。

​

边界与失效场景

海勒姆定律在广泛共享、长期存活的接口上最强。只有两个用户的个人脚本可以自由改；有数百万客户端的平台 API 不行。 它不能当作永远不改进的借口。定律预测破坏风险，并不禁止变更。它要求你为排查、沟通与迁移定价——而不是永久冻结。 常见误用是一边骂用户“误用” API，一边继续发出高度可见却未文档化的怪癖。可见却不清晰，就是在邀请依赖。另一种误用是把每个毛刺都奉为神圣：有些 bug 仍应通过带版本的破坏与迁移路径修复，尤其当它们制造安全或正确性债务时。

​

常见误区

用清之前，先把预测、归咎与设计策略分开。

​

相关概念

这些页面有助于把海勒姆定律放在互操作、系统生长与意外耦合之中理解。

​

一句话总结