Rust 系统开发

Rust 代码评审中的常见问题

Rust 的类型系统能帮助开发者在编译期规避大量内存安全问题，但实际项目里仍有许多约定俗成的写法没有被正确执行：在库代码里随意调用 .unwrap()、为了图方便直接 clone() 大对象、在 async 函数里跨 .await 持有 MutexGuard 导致死锁、滥用 Arc<Mutex<T>> 而忽略了 channel 的解耦能力。这些问题往往要到运行时甚至生产环境才暴露，排查成本极高。

技能如何工作

这个技能把 Rust 社区公认的工程实践整理成一套可执行的检查清单，覆盖以下核心模块：

• 所有权与借用：优先使用 &T、&mut T 借用而非转移所有权，仅在必要时才 clone。
• 错误处理：库层用 thiserror 定义错误类型并通过 ? 传播，应用层用 anyhow 简化处理，生产路径杜绝 .unwrap()。
• Trait 与泛型：以 trait 做抽象边界，提升代码的可测试性。
• 异步模式：用信号量或 buffer_unordered 控制并发度，避免无限制的 spawn。
• Builder 模式：为复杂的配置结构体提供链式构造。

此外，技能明确列出了反模式清单，例如未记录安全不变量的 unsafe 块、返回 Result 却不加 #[must_use] 等，方便在评审时逐项对照。

适用边界

这套指南面向的是中大型 Rust 项目的编码规范与评审场景。对于原型验证或一次性脚本，部分约束（如严格的错误类型分层）可以适当放宽。技能不替代编译器和 Clippy 的自动化检查，而是作为人工评审的补充；建议与 cargo clippy 配合使用，确保 lint 警告被清零。