Rust代码审查：每个高级开发者都会提出的5点意见

引言：为什么Rust如此严格，代码审查如何帮助你保持清醒

你用Rust写了代码。它编译通过了——太好了！但问题是：高级开发者打开你的Pull Request，叹了口气，开始写评论。熟悉吗？Rust是一种有着独特哲学的语言：它信任你，但会检查一切。然而，编译器看不到经验丰富的眼睛能看到的东西。它不会说：“嘿，这可以做得更优雅”或“你的代码在泄漏——不是内存，而是性能”。

在本文中，我们将进行Rust代码审查并分析高级开发者的典型意见。你将学习如何将“仅仅能工作的代码”转变为地道且可靠的代码。开始吧！

1. 忽视类型系统：“让我把所有东西都包进String里”

新手最常见的错误是在需要具体类型的地方使用String或通用类型。高级开发者会说：“你的类型应该反映业务逻辑，而不仅仅是一个字符串”。

问题：语义丢失

假设你正在编写一个处理电子邮件地址的函数：

fn send_email(to: String, subject: String, body: String) {\n    // ...\n}

这有什么问题？你可能会混淆to和subject——编译器不会注意到。高级开发者会建议使用newtype模式：

struct Email(String);\nstruct Subject(String);\nstruct Body(String);\n\nfn send_email(to: Email, subject: Subject, body: Body) {\n    // ...\n}

这看起来多余吗？在Rust代码审查中，这种方法是黄金标准。它使代码自文档化，并排除了一整类错误。

2. 滥用clone()：复制并不意味着拥有

初级开发者经常在编译器抱怨借用时到处使用.clone()。高级开发者会说：“你只是向借用检查器投降了。换个思路”。

示例：多余的clone

fn process(data: Vec<i32>) {\n    let first = data[0].clone();\n    let second = data[1].clone();\n    // ...\n}

i32实现了Copy trait——这里的clone()完全多余。但问题更深层：如果你克隆大型结构（例如Vec或String），你会严重影响性能。

正确的方法是使用引用：

fn process(data: &[i32]) {\n    let first = &data[0];\n    let second = &data[1];\n    // ...\n}

在Rust代码审查中，你必须解释为什么克隆。如果答案是“为了让编译器不抱怨”——准备好接受严厉的评论。

3. 糟糕的错误处理：.unwrap()不是最终解决方案

高级开发者讨厌生产代码中的unwrap()和expect()。为什么？因为它们将潜在可恢复的错误变成了恐慌。而Rust中的恐慌意味着程序崩溃。

这段代码有什么问题？

let file_content = std::fs::read_to_string("config.txt").unwrap();

如果文件不存在——程序会崩溃。高级开发者会建议：

let file_content = std::fs::read_to_string("config.txt")\n    .map_err(|e| format!("Failed to read config: {}", e))?;

使用?运算符和自定义错误类型。这是地道Rust的基础。在Rust代码审查中，这是最常见的意见之一。

4. 忽视性能：内存分配和迭代器

Rust是一种系统级语言。高级开发者不仅会关注安全性，还会关注速度。一个典型问题是创建不必要的集合。

示例：不必要的收集

let numbers: Vec<i32> = (0..100).collect();\nlet doubled: Vec<i32> = numbers.iter().map(|x| x * 2).collect();