> ## 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.
# 林纳斯定律
> 林纳斯定律指出：审阅者足够多时，几乎每个缺陷都会更快被发现并修好。了解起源、用法与开放审查失效之处。
**类别**: 定律
**类型**: 开源协作与软件质量启发式
**来源**: Eric S. Raymond，《大教堂与集市》（First Monday，1998；O'Reilly 书，1999）；以 Linus Torvalds 命名
**别名**: “眼睛足够多，所有 bug 都是浅的”
**快速回答** — **林纳斯定律**（Linus's Law）主张：测试者与共同开发者足够多时，几乎每个问题都会很快被刻画清楚，并且对某人来说修复显而易见。更多眼睛不会凭空制造能力；它提高“有人正好具备正确视角”的概率。用它设计评审与发布闭环——不要当成热门代码必然安全的保证。
## 什么是林纳斯定律？
**林纳斯定律**（Linus's Law）是一条软件工程主张：广泛而多样的审视，往往比封闭的“大教堂式”开发，更容易让缺陷变浅——更容易发现、也更容易修好。
> 眼睛足够多，所有 bug 都是浅的。
Eric S. Raymond 更完整的表述是：只要 beta 测试者与共同开发者足够多，几乎每个问题都会很快被刻画清楚，并且对某人来说修复显而易见。想象公园里丢了一把钥匙：一个人可能走好几天都找不到；上百人反复经过同一条路，找到的机会就会上升。代码里，“浅”不是说永远琐碎——而是说暴露给足够多认真的人之后，刻画与修复会加速。
### 林纳斯定律的三层理解
* **入门**：许多仔细的读者，比小小的封闭团队更快发现 bug。
* **实践**：尽早发布以换反馈，但前提是审阅者真的能运行、阅读并报告变更。
* **进阶**：眼睛有用，当激励、工具与专长覆盖了风险面；缺这些覆盖时，单靠流行度仍会漏掉深缺陷。
## 起源
**Eric S. Raymond** 在《大教堂与集市》中创造了 **Linus's Law** 这一名称，文章于 **1998 年 3 月**在 *First Monday* 广泛发表，后扩展为 O'Reilly 著作（**1999**）。他以 **Linus Torvalds** 命名，因 Linux 的开发风格——尽早并经常发布、对外部贡献开放——与由小团队孤立打造的“大教堂”项目形成对照。
Raymond 认为：大教堂建造者把 bug 当作深而阴险的现象，因此很少发布；集市建造者则假定，一旦许多共同开发者猛砸每个版本，bug 大体上会变浅。Torvalds 后来澄清了 Raymond 采纳的重要区分：*发现* bug 的人，往往不是*理解并修复*它的人——而发现常常更难。因此该定律依赖许多头脑的并行搜索，而不是要求每个报告者都是调试大师。
## 核心要点
林纳斯定律是关于搜索与视角多样性的赌注，不是给仓库加星就能施展的魔法。
加人只有在他们走不同路径、平台与威胁模型时才有用。闲逛围观者不是 Raymond 意义上的眼睛。
发现与修复是不同工作。社区报告能浮现症状；维护者仍需专长来修补根因——这与[布鲁克斯定律](/zh/laws/brookss-law)不同，后者警告加人可能因协调成本拖慢交付。
频繁发布给审阅者反复发现回归的机会。没有可运行产物与清晰报告渠道，开放只是表演。
广泛使用的代码仍可能藏着很少被走到的路径。把社区审阅与测试、模糊测试、专项审计并用——尤其在激励薄弱处；[海勒姆定律](/zh/laws/hyrums-law)也提醒：沉默依赖可能掩盖破损边缘。
## 应用场景
只要你能真正扩大“谁看见、谁加压”的人，就用林纳斯定律。
公开变更说明，邀请可复现的缺陷报告，并把安全问题路由给能审查密码学与内存安全的人——不只是功能爱好者。
跨团队轮换审阅者，要求可运行演示，并把“没跑过就 LGTM”当作失败的眼睛。
招募匹配真实边界情况的用户（语言区域、设备、无障碍），让反馈覆盖生产中会断裂的表面。
尽早把草稿分享给不同意你的同伴；[坎宁安定律](/zh/laws/cunninghams-law)是近亲——错误或不完整的主张，往往比私下打磨更快招来纠正。
## 经典案例
Heartbleed 说明“足够多眼睛”并非自动发生。OpenSSL 的 TLS Heartbeat 缺陷（**CVE-2014-0160**）于 **2011 年 12 月 31 日**引入源码树，随 OpenSSL **1.0.1** 在 **2012 年 3 月 14 日**广泛发布，并在 **2014 年 4 月 7 日**随 **1.0.1g** 修复而公开披露——在支撑大量公共网络的库里暴露超过两年。缺失的边界检查让攻击者每次请求可读出约 **64 KB** 进程内存，可能包含密钥与凭证。
OpenSSL 是开源且被重度使用；即便如此，该缺陷仍未被一般流量发现，直到专家级发现（包括与 Google Security、Codenomicon 相关的报告）推动协调披露。教训不是开放审查无用——而是林纳斯定律需要*相关*的眼睛落在*被走到*的代码路径上，并有动机去找沉默的内存缺陷。边界同样重要：披露之后，同一开源生态迅速发布补丁；失败在于长期未被察觉的深度，而非刻画之后无法响应。
## 边界与失效场景
当“许多用户”并不是“许多审阅者”时，林纳斯定律失效。下载量不是审计。密码学、并发与硬件相关缺陷，往往需要休闲贡献者所缺乏的稀缺专长与工具。
社会动力学压制报告时也会失效：敌意的维护者文化、不清的贡献路径，或责任恐惧，都会缩小有效眼睛数量。
常见误用是声称开源自动比闭源更安全。开放是获得审视的机会，不是正确性证书。另一种误用是向项目倾倒未经训练的审阅者并期待质量上升——没有分流的噪声，会重现布鲁克斯定律式的协调成本。
## 常见误区
先把口号与使其成立的条件分开。
不对。它预测的是：当足够多有能力的审阅者在看时，刻画会更快。没有审查覆盖的流行度，仍可能让深缺陷潜伏数年。
不对。Eric S. Raymond 根据 Torvalds 的 Linux 实践命名并推广。Torvalds 细化了发现与修复的区分；他并未把它发表为数学定律。
不对。Star 衡量关注，不衡量已执行的审查。从不运行代码、从不读风险模块、从不提 issue 的眼睛，不会让 bug 变浅。
## 相关概念
这些页面有助于把林纳斯定律放在协作限度、激励与失败模式之中理解。
加人可能抬高协调成本——只有沟通仍可工作时，眼睛才有帮助。
错误主张会招来纠正；与公开暴露与回应的相关动力学。
用户依赖一切可观察行为——包括“足够眼睛”从未挑战过的 buggy 行为。
宽容有助于互通，但也可能隐藏审阅者仍须检查的协议怪癖。
可能出错的事仍可能出错——审视减少意外，并不消灭失效模式。
能工作的复杂系统从简单系统长成；早期暴露可在复杂度掩盖缺陷前抓住它们。
## 一句话总结
把工作开放给真正能运行并挑战它的人——没有覆盖的眼睛，只是观众。