Google 的 Rust Style Guide，藏着哪些不一样的工程思考？
内容提要
Google发布Rust风格指南，将代码风格视为大规模工程治理工具，服务于可读性、可维护性和自动化批量修改。指南建议优先拆分小Crate以明确依赖边界，优先使用借用和唯一所有权而非Rc、Arc和clone，公共API采用&str、&[T]等通用类型，用enum表达状态，公共枚举考虑#[non_exhaustive]以预留演进空间，并克制使用Trait、宏和复杂抽象。部分规则（如Chromium禁用async/.await）属特定工程选择，普通项目应借鉴原则而非照搬。
延伸解读
规则背后的工程规模逻辑
Google 的 Rust 风格指南并非另起炉灶，而是明确要求先遵循社区规范，仅在冲突时使用自身规则。其额外规则服务于超大型代码库的特定目标：可读性、可维护性、自动化批量修改（LSC）和降低长期维护成本。理解这一点，才能避免把针对 Chromium 等环境的规则误当作通用最佳实践。
小 Crate 与所有权建议的适用边界
指南建议优先拆分小 Crate 以明确依赖边界，但该规则带有 [chrome] 标记，主要针对 Chromium 的构建环境。普通 Cargo 项目若盲目拆分，可能增加依赖管理和发布复杂度。同样，优先借用和唯一所有权、少用 Rc/Arc/clone 是合理的默认顺序，但指南也承认在借用关系过于复杂时，复制或共享所有权仍是可接受的工程选择。
公共 API 演进中的真实权衡
对公共枚举使用 #[non_exhaustive] 可以降低库作者新增变体时的下游协调成本，但代价是调用者可能用通配分支掩盖本应显式处理的新状态。指南并未给出绝对答案，而是提示根据使用场景权衡：内部应用、同一团队维护时，强穷尽匹配更有价值；面向大量外部使用者的公共库，则更需为未来演进预留空间。
克制抽象与特定环境限制
指南建议优先使用普通函数、类型和模块，仅在确有需要时引入 Trait、宏或复杂抽象，并提醒迭代器链并非越长越好。Chromium 禁用 async/.await 也属于特定运行时和基础设施约束下的工程选择，而非对 Rust 异步模型的否定。普通项目应区分语言能力、运行时能力和工程约束，借鉴原则而非照搬规则。
Q&A
Google 为什么需要制定自己的 Rust 风格指南？
Google 的 Rust 代码分布在多个大型项目中，不同团队习惯不同，局部设计选择可能产生全局影响。指南旨在统一规则，提升可读性、可维护性和自动化批量修改能力，降低大规模变更的成本与风险。
Google 建议如何设计 Rust 的所有权，避免滥用 Rc、Arc 和 clone？
优先使用借用和唯一所有权，共享所有权应源于真实需求。先考虑借用能否解决问题，再判断是否需要独立所有权，最后才选择共享所有权机制或复制数据。
为什么 Google 建议公共枚举使用 #[non_exhaustive]？有什么权衡？
为公共 API 未来增加变体预留空间，降低下游兼容性破坏风险。代价是调用者可能使用通配分支，削弱编译器对穷尽匹配的检查。适用于公共库，内部应用可保留强穷尽匹配。
Google 对 Trait、宏和复杂抽象的使用持什么态度？
克制使用。默认优先固有实现（impl Type），仅在需要泛型约束、动态分发等明确问题时引入 Trait；宏的优先级低于普通函数和类型，避免为减少重复代码而创建小语言。
Chromium 为什么禁止使用 async/.await？这是否说明 Rust 异步不好？
这是 Chromium 特定工程环境的选择，因其已有成熟的任务调度和线程模型，引入另一套并发模型会增加复杂性。并非否定 Rust 异步，普通项目应区分语言能力、运行时能力和工程约束。
普通 Rust 项目应该如何借鉴 Google 的 Rust 风格指南？
分三层：直接采用低成本高收益规则（如 rustfmt、标准 Trait、文档注释、避免无必要 glob import）；根据项目性质决定 API 规则；不盲目复制特定代码库的架构规则（如小 Crate、扁平布局），需评估自身构建系统和收益。
