Rust 所有权实战：从 clone 滥用到借用，把性能与内存吃透

新手最常见的两个误区

刚写 Rust 的人，遇到编译器报 move 或 borrow 错误，第一反应往往是到处加 .clone() 或者把参数都改成 String。代码是能编译了，但代价是大量无意义的堆分配和深拷贝，性能悄悄劣化。

所有权（ownership）的本质是：同一份内存在任意时刻要么只有一个所有者，要么有多个不可变借用，要么有一个可变借用，三者互斥。理解这条规则，比背语法更重要。

反例：不必要的 clone

struct User {
    name: String,
    email: String,
}

// 反例：仅仅为了读一下 name 就 clone 了整个 String
fn greet_bad(u: User) -> String {
    let n = u.name.clone(); // 多余分配
    format!("你好, {}", n)
}

正例：用借用替代 move

只读场景用 &T 借用，既不转移所有权，也不拷贝数据；需要修改再考虑 &mut T。

fn greet(u: &User) -> String {
    format!("你好, {}", u.name) // 直接借用，零拷贝
}

// 需要返回内部字段时，返回引用而非克隆
fn name_of(u: &User) -> &str {
    &u.name
}

fn main() {
    let u = User {
        name: "张三".to_string(),
        email: "zhang@demo.com".to_string(),
    };
    println!("{}", greet(&u));
    println!("{}", name_of(&u));
    // u 仍然可用，因为 greet 只是借用了它
}

什么时候才该 clone

• 确实需要把数据存到另一个拥有独立生命周期的结构里，且无法用引用表达所有权关系。
• 需要并发把数据 move 进别的线程，且 Arc 不合适（例如要可变）。
• 小对象、热路径之外的初始化逻辑，clone 的可读性收益大于性能损耗时可以接受。

借用检查器逼你写出更安全的并发

Rust 把「数据竞争」挡在编译期。下面这个例子若试图在闭包里同时可变借用两次，编译器直接拒绝，而不是等到运行时崩溃。

use std::collections::HashMap;

fn count_words(map: &HashMap<String, u32>, key: &str) -> u32 {
    *map.get(key).unwrap_or(&0)
}

// 多个 &map 的不可变借用可以共存，安全
fn main() {
    let mut map = HashMap::new();
    map.insert("rust".to_string(), 3);
    let a = count_words(&map, "rust");
    let b = count_words(&map, "go");
    println!("{} {}", a, b);
}

结论：把 clone 当兜底而不是默认。先用 &T 借用，编译器放行就说明没有隐藏的所有权陷阱；只有真正需要转移数据时才 move 或 clone，这样写出的 Rust 既安全又高效。