Rust 所有权与生命周期开发短记：一次失败实验能说明什么

Rust 所有权与生命周期开发短记：一次失败实验能说明什么

我学所有权时，很容易在看到报错后立刻去搜答案。后来发现，把报错缩成十几行代码再看，往往比套一段“万能写法”更有用。下面这个例子没有运行时故障，编译器在修改HashMap时就把借用冲突拦住了。

use std::collections::HashMap; fn keep_small_values(scores: &mut HashMap<String, 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 再删除”时，我仍要自己确认是否会多一次分配、是否符合当前函数的语义。

一次失败实验说明的只是这条借用关系，不足以推出整个项目的设计结论。把边界留在这里，反而更方便下次遇到相似报错时复用。