• 同一个项目，两种质量标准
• 崩溃也没关系的两个前提
• 为什么不直接要求所有代码都高标准
• 从中学到了什么

rust-analyzer 有一个特点，它既是一个编译器，又是一个 IDE。这两种性质吸引了完全不同的贡献者。

编译器核心部分吸引的是少数深度贡献者，他们有持续的时间和精力投入。matklad 对这部分代码的质量要求很严格。

IDE 的各种功能（跳转定义、自动补全、重构提示等）则适合另一类人，matklad 管他们叫「周末战士」，他们没有长期参与项目的精力，但可以花一两个小时实现某个功能来满足自己的需求。

对这类贡献者的代码，matklad 定的标准出人意料地低，只要正常流程能跑通、有测试就行。崩溃也没关系。

这听起来像是放纵，但其实是算计过的选择，而且有两个技术前提。

要让「低质量功能代码」不拖垮整个项目，rust-analyzer 必须同时满足两个条件。

1. *质量隔离*，一个功能的崩溃不能蔓延到其他功能。rust-analyzer 在运行时用 catch_unwind （Rust 的异常捕获机制）把每个功能的错误隔离起来。某个功能崩了，也不影响其他功能继续正常工作。
2. *用户无感知*，崩溃不能让用户看到。rust-analyzer 不会让功能代码直接操作实时数据，而是给每个功能一份只读的源代码快照。功能只能读，不能改原数据，所以即使崩了也不会弄脏主数据。

两个条件缺一个都不行。没有质量隔离，bug 会从一个功能蔓延到另一个。没有只读快照，崩溃会搞乱数据。

因为核心和边缘本身就不该用同一把尺子量。matklad 把提供基础设施的核心代码（他称之为 spine）的质量抓得很紧，核心代码一旦出问题，所有功能都受影响，没有隔离可言。但边缘功能不一样，只要隔离得当，质量低一点不会伤筋动骨。

而这个项目的激励结构也决定了必须这么做。

matklad 花了大量精力降低参与门槛：不依赖 rustc（Rust 官方编译器，代码量巨大，编译极慢），只用稳定版 Rust（不需要装实验版本），不依赖 C 语言库（装了 Rust 就能编译，不用额外装 C 工具链），测试套件秒级完成。这些全是为了让深度贡献者更容易上手。但 IDE 功能太多了，光靠深度贡献者做不完。

降低功能代码的质量门槛，是为了让「周末战士」也能贡献。如果每个功能 PR 都要求核心级别的质量，这些贡献者根本不会出现。而功能即使有 bug，只要隔离得当，不仅不会有什么影响，而且还能吸引更多人来修复。

这个策略不是所有项目都能用的。它要求系统架构天然支持功能隔离，并且核心和边缘的边界足够清晰。

但在满足条件时，它给了一个实用的思路，质量标准不需要全局统一，可以按模块的隔离程度和贡献者类型做差异化。质量标准由三个因素决定：模块在系统中的位置、谁来写它、它崩了影响多大。

还有一件事要注意：项目会向着你想象不到的方向发展。rust-analyzer 最初是给 rustc 做 LSP 架构原型的实验品，结果实验没按预期发展，反而搞出了个编译器。类似的事也发生在 uutils 项目上，最初是 Rust 学习者的练习场，后来成了 Ubuntu 的 coreutils 实现。分层质量策略在特定阶段有效，但不能指望项目的目标和激励结构永远不变。