Rust 所有权与生命周期开发短记一次失败实验能说明什么我学所有权时很容易在看到报错后立刻去搜答案。后来发现把报错缩成十几行代码再看往往比套一段“万能写法”更有用。下面这个例子没有运行时故障编译器在修改HashMap时就把借用冲突拦住了。use std::collections::HashMap; fn keep_small_values(scores: mut HashMapString, i32) { scores.retain(|_, value| *value 10); } #[test] fn retain_removes_large_values() { let mut scores HashMap::from([ (rust.to_owned(), 9), (wasm.to_owned(), 12), ]); keep_small_values(mut scores); assert_eq!(scores.len(), 1); assert!(scores.contains_key(rust)); }我最初的写法是在iter()遍历时调用remove()。前者持有不可变借用后者需要可变借用所以编译不过。retain把“判断”和“删除”放在 API 内部完成意图也更清楚。遇到这类问题时可以先保留不能编译的最小片段再运行rustc --explain E0502最后写一个能验证修改行为的测试。有时我会让 AI 帮忙解释错误信息但只把错误码和自己写的最小代码发给它不贴真实项目文件。它的输出适合作为解释或备选方案不能替代编译器和测试。比如 AI 提议“先收集 key 再删除”时我仍要自己确认是否会多一次分配、是否符合当前函数的语义。一次失败实验说明的只是这条借用关系不足以推出整个项目的设计结论。把边界留在这里反而更方便下次遇到相似报错时复用。 Rust 所有权与生命周期开发短记：一次失败实验能说明什么
Rust 所有权与生命周期开发短记一次失败实验能说明什么我学所有权时很容易在看到报错后立刻去搜答案。后来发现把报错缩成十几行代码再看往往比套一段“万能写法”更有用。下面这个例子没有运行时故障编译器在修改HashMap时就把借用冲突拦住了。use std::collections::HashMap; fn keep_small_values(scores: mut HashMapString, i32) { scores.retain(|_, value| *value 10); } #[test] fn retain_removes_large_values() { let mut scores HashMap::from([ (rust.to_owned(), 9), (wasm.to_owned(), 12), ]); keep_small_values(mut scores); assert_eq!(scores.len(), 1); assert!(scores.contains_key(rust)); }我最初的写法是在iter()遍历时调用remove()。前者持有不可变借用后者需要可变借用所以编译不过。retain把“判断”和“删除”放在 API 内部完成意图也更清楚。遇到这类问题时可以先保留不能编译的最小片段再运行rustc --explain E0502最后写一个能验证修改行为的测试。有时我会让 AI 帮忙解释错误信息但只把错误码和自己写的最小代码发给它不贴真实项目文件。它的输出适合作为解释或备选方案不能替代编译器和测试。比如 AI 提议“先收集 key 再删除”时我仍要自己确认是否会多一次分配、是否符合当前函数的语义。一次失败实验说明的只是这条借用关系不足以推出整个项目的设计结论。把边界留在这里反而更方便下次遇到相似报错时复用。