海勒姆定律

​

什麼是海勒姆定律？

海勒姆定律（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 仍應透過帶版本的破壞與遷移路徑修復，尤其當它們製造安全或正確性債務時。

​

常見誤區

用清之前，先把預測、歸咎與設計策略分開。

​

相關概念

這些頁面有助於把海勒姆定律放在互操作、系統生長與意外耦合之中理解。

​

一句話總結