Rust 所有权与生命周期

Rust 的所有权规则不是另一套垃圾回收器，而是编译期的资源管理模型。它把“谁负责释放资源”和“什么时候可以读写”写进类型与作用域，让很多悬垂引用和数据竞争在编译阶段就无法表达。理解它的关键，是跟踪一个值在某个时刻由谁拥有、谁在借用，以及借用有效到哪里。

移动与借用：先看值的去向

对多数拥有堆资源的类型，赋值会移动所有权：原绑定不再可用，避免两个所有者重复释放同一资源。实现 Copy 的简单值则按值复制。

let first = String::from("agent");
let second = first;
// println!("{first}"); // 编译错误：String 已移动给 second
println!("{second}");

fn normalized_len(value: &str) -> usize {
    value.trim().len()
}

let label = String::from("  MCP  ");
let size = normalized_len(&label);
println!("{label}: {size}"); // 借用结束后，label 仍归调用者所有

需要继续使用原值时，先考虑借用；只有确实需要第二份独立数据时才 clone()。对 String、Vec<T> 等堆分配类型，clone 通常会分配并复制内容。API 用 &str 接收只读文本，往往比要求调用方交出一个 String 更灵活。

借用规则与可变性

在某个时间范围内，可以有多个不可变引用，或者一个可变引用，不能同时存在可变与不可变访问。这使编译器能排除安全 Rust 中的一类数据竞争。

fn append_suffix(name: &mut String) {
    name.push_str("-worker");
}

let mut service = String::from("order");
let view = &service;
println!("{view}");
// append_suffix(&mut service); // view 后续仍要使用时，不能同时可变借用
append_suffix(&mut service);
println!("{service}");

借用检查按引用的实际使用范围判断，而不是简单地按大括号判断。编译器常能让不可变借用在最后一次使用后结束；但把引用放进结构体、闭包或跨 .await 保存时，借用范围可能延长，需要更明确地处理所有权。

生命周期标注表达“谁依赖谁”

大部分局部引用的生命周期由编译器推断。显式生命周期常出现在返回引用的函数上，用来描述返回值与输入值的有效期关系；它不会延长数据寿命，也不是运行时定时器。

fn longer<'a>(left: &'a str, right: &'a str) -> &'a str {
    if left.len() >= right.len() { left } else { right }
}

签名说明返回切片借用自两个输入中至少存活到共同 'a 的那一个。调用方仍需保证被引用的原始字符串在使用返回值期间有效。

带引用的结构体也要声明引用有效期：

struct HeaderView<'a> {
    name: &'a str,
    value: &'a str,
}

fn first_header<'a>(headers: &'a [(String, String)]) -> Option<HeaderView<'a>> {
    headers.first().map(|(name, value)| HeaderView {
        name,
        value,
    })
}

在长期存活的业务对象里存借用字段，会把生命周期要求传递给所有拥有者。若对象需要脱离请求缓冲区、放进缓存或跨任务保存，通常应拥有数据（例如 String），或者存储稳定的 ID，而不是试图用复杂标注延长一次请求的输入引用。

服务 API 的边界怎么选

短期只读处理：参数用 &str、&[T]，避免不必要的所有权转移。
接管数据并保存：用 String、Vec<T> 等拥有类型表达所有权归服务层。
多处长期共享：先判断是不是需要复制；共享只读数据可考虑 Arc<T>，可变共享数据还要配同步原语。
返回引用：仅在返回值确实应借用输入或 self，且调用方能自然管理生命周期时使用。

struct UserProfile {
    display_name: String,
}

impl UserProfile {
    fn display_name(&self) -> &str {
        &self.display_name
    }

    fn replace_display_name(&mut self, name: String) {
        self.display_name = name;
    }
}

这里 getter 借用内部字符串，setter 接收新的拥有值。若边界来自 JSON 反序列化，通常 DTO 应拥有 String，因为请求 body 解析完后不会继续借用原始缓冲区。

编译器报错的排查方法

先指出每个值的所有者：看值在哪创建、何时 move、函数返回后由谁持有。
缩小引用作用域：把引用消费提前，或将读取结果复制成小的 owned 值，避免把引用活得过长。
让函数返回拥有的数据：如果返回借用导致调用方被迫跟随多个输入生命周期，试试返回 String/Vec。
最后再加生命周期参数：标注只能描述已存在的关系，无法让局部值“活得更久”。
区分编译器安全与业务正确：所有权检查能阻止许多内存错误，但不能判断订单状态是否允许转换。

Rc、Arc、RefCell、Mutex 都是有用工具，但不是借用检查失败的通用修复。它们把独占所有权变成共享所有权或运行时检查，会增加同步和错误处理责任。先让数据归属和 API 边界清楚，再引入共享。

常见踩坑

遇到 move 就直接 clone：这能消掉报错，却可能掩盖所有权设计和复制成本。先确认是否只需借用。
把生命周期理解成对象存活控制：生命周期只验证引用在有效期内，既不分配也不释放数据。
在 HTTP handler 里返回借用 request body 的片段：body 解析后的临时缓冲区结束后就不能引用。需要跨层保存时转换成拥有类型。
把 Arc 当成线程安全锁：Arc<T> 只原子计数共享所有权；要共享可变状态还需 Mutex、RwLock 或消息传递。
过早上 unsafe 绕过借用检查：错误转移到运行时内存安全责任。优先重设拥有边界，只有证明了不变量并补足测试后才考虑 unsafe。