Rust所有权入门借用检查器在防什么
CloudWhite
9 分钟阅读
Rust 不用垃圾回收也不靠手动 free，而是在编译期用所有权规则保证"同一块内存要么唯一拥有、要么可被安全地读"——借用检查器防的是悬垂引用、数据竞争和重复释放。这套机制把 C/C++ 里最头疼的一类 bug，从运行期、甚至从上线后,提前到编译期就拦下。代价是初学时要和编译器反复拉扯，但拉扯的对象恰好是过去要花半夜排的线上事故。
所有权三条规则
每个值有且仅有一个所有者；同一时刻只有一个所有者；所有者离开作用域，值被自动释放：
{
let s = String::from("hello"); // s 拥有这块堆内存
// 使用 s
} // 作用域结束，s 被 drop，内存回收
没有 GC 循环，也没有 free 要你记得调。释放发生在 } 处，确定性且零运行时负担。这条规则回答了"谁负责清理"：永远是那个唯一的所有者，且只在它离开时。
移动把所有权交出去
堆上的类型（如 String）赋值不是拷贝，而是移动——原变量失效，避免两个变量都以为自己拥有同一块内存：
let s1 = String::from("hi");
let s2 = s1; // 所有权移到 s2
// println!("{}", s1); // 编译错误：s1 已不再拥有
栈上的 Copy 类型（i32、bool、元组等）则按位复制，移动语义不触发。区分标准是该类型是否实现了 Copy trait——只有完全由栈上数据组成、且克隆成本等于拷贝的类型才该标 Copy。标了 Copy 的类型移动时仍是复制，原变量继续有效。
借用：不抢所有权地用
用 & 借引用，借用时原所有者 retains 所有权：
fn len(s: &String) -> usize {
s.len()
}
let s = String::from("hi");
let n = len(&s); // 借用，s 仍可用
借用分两类：共享借用 &T（可多个同时存在，只读）和可变借用 &mut T（同一时刻只能有一个，可写）。检查器强制"可读可写不能并存"——要么一群人只读，要么一个人独写，杜绝一边写一边读导致的数据撕裂。
检查器到底在挡什么
悬垂引用：返回局部变量的引用会被拒，因为变量走了引用就指向已释放内存：
fn dangle() -> &String { // 报错
let s = String::from("x");
&s
}
数据竞争：多线程下若允许一个线程写、另一个同时读同一数据，运行期才会暴露的 bug，Rust 在编译期通过"可变借用唯一"直接禁止。这是 Rust 敢说"无畏并发"的根基——不是靠纪律，而是靠类型系统把竞争挡在门外。
重复释放：移动后原变量不可访问，从根上消除了 C++ 里 delete 两次的那类崩溃。所有权唯一，释放只发生一次。
let mut data = vec![1, 2, 3];
let r1 = &data;
let r2 = &data; // 两个共享借用，OK
// let m = &mut data; // 报错：已有不可变借用时不能可变借用
println!("{:?} {:?}", r1, r2);
生命周期标注
当函数返回的引用"取自哪个参数"编译器推断不出时，要写生命周期参数：
fn longest<'a>(x: &'a str, y: &'a str) -> &'a str {
if x.len() > y.len() { x } else { y }
}
'a 读作"返回值的存活期不超过 x 和 y 中较短的那个"。多数情况编译器能自动推导（生命周期省略规则），只有返回引用又涉及多个输入时才手写。生命周期不延长任何对象的存活，它只是给编译器一个"比较两条引用存活期"的约束，真正的释放仍由所有权决定。
边界与坑
clone 能绕过移动，但它是真拷贝、有堆分配成本，别当作逃避设计的所有权方案的万能钥匙。先想清楚谁该拥有，再决定要不要复制。经验上，频繁 clone 往往意味着数据结构里共享关系没设计好。
Rc<T> / RefCell<T> 是运行期借用记账的逃生舱：Rc 允许多个所有者（引用计数），RefCell 在运行期做借用检查。它们把部分检查从编译期推迟到运行期，用得好解耦，用得多就抵消了 Rust 的卖点——RefCell 的 borrow 冲突会变成运行期 panic，检查器的保护被削弱了。
可变借用在作用域内"存在即独占"。下面这种常见写法会卡住：
let mut v = vec![1];
let head = &v[0];
v.push(2); // 报错：head 借用未结束，不能改 v
println!("{}", head);
把 println! 提到 push 之前，或缩短借用作用域即可。编译器报的"借用活得比使用久"通常就是这个原因。
Copy 与 Drop 互斥：类型若实现了 Drop（自定义释放），就不能是 Copy，否则释放逻辑会跑多次。这是规则自洽的一部分，编译器会直接拒绝这种组合。
字符串字面量 &str 与 String 的取舍也常被借用语义困扰：&str 是借用、零成本；String 是拥有、可改。函数参数优先 &str 能同时接住两种，返回时若需要拥有数据才返回 String。
所有权的学习曲线集中在"编译器逼你显式表达数据的归属"。一旦接受"谁拥有、谁能借、借多久"这套心智模型，大量并发与内存 bug 会在写代码的那一刻被挡下，而不是上线后半夜告警。它把"内存安全"从一个靠经验维护的纪律，变成了编译器可证明的性质。
所有权与并发的衔接
Send 与 Sync 两个自动 trait 把所有权规则延展到线程边界：Send 表示值可转移到另一线程拥有，Sync 表示值可被多线程同时借引用。String、Vec 是 Send 但独占、不可同时共享可变；Arc<T> 是 Sync，多线程共享只读；Mutex<T> 把 Sync 变成"可通过锁获得可变"。规则统一为：跨线程传数据靠移动（转移所有权，原线程不再碰），跨线程共享靠 Arc 加锁。检查器在编译期拒绝"把非 Send 的东西丢进线程"或"把可变引用同时逃出多线程"，所以数据竞争在编译期就被挡，而不是运行期偶发。
经验上，能用"移动所有权"解决的就用 Arc<T> 之前的 std::thread::spawn 传参移动，避免共享；实在要共享再上 Arc<Mutex<_>>。共享越少，锁竞争与死锁面越小，也越贴近 Rust 想要你写的形态。
常见编译错误速查
"borrowed value does not live long enough"：借用的存活期超过了被借对象，通常是函数返回了局部变量的引用，或借用在使用点之后对象才释放。解法：让函数返回所有权（String 而非 &String），或把对象生命周期拉长到借用之外。
"cannot borrow as mutable because it is also borrowed as immutable"：同一作用域内既有共享借用在活、又想拿可变借用。缩小前一个借用的作用域（提前用完、提前 drop 或把使用拆开）即可。
"partial move"：对结构体部分字段移动后，再去整体使用原结构体，编译器报部分移动。若要整体移动就整体 let s = other;，若只想取字段就只移动那个字段、剩余字段另作处理。
"value moved here, in previous iteration of loop"：循环里把迭代变量移动走了，下一轮又用。改成每次循环重新生成、或借用而非移动、或迭代引用。
clone 救急但要付代价：当借用关系实在绕不开、又需要独立副本时 clone 能编译通过，但它是堆分配、有成本，应作为"先让代码跑起来"的临时解，之后回到重新设计归属。长期靠 clone 掩盖所有权问题，等于放弃了 Rust 大半优势。
所有权系统前期拦你的每一次，几乎都对应着 C/C++ 里一次真实的悬垂、竞争或双重释放。把编译器和你对立着看会很难受，把它当成"一个比你还怕出事的搭档"会更顺——它不允许的写法，往往正是过去让你熬夜的那一类。
浏览 8
点赞 0
评论 0