作为经验丰富的 Java 开发者，我们对 ArrayList、String 和 HashMap 的强大功能了如指掌。它们是 Java 集合框架的核心，也是我们日常编程的得力干将。Rust 同样提供了功能对等的集合类型，但它们的行为模式，尤其是内存管理方式，与 Java 有着天壤之别。

本章我们将探索 Rust 三大核心集合类型：Vec<T>（向量）、String（字符串）和 HashMap<K, V>（哈希映射）。它们有一个共同点：其数据都存储在堆（Heap）上。这意味着，它们都必须严格遵守我们在前面章节学到的所有权规则。理解这些规则如何应用在集合类型上，是写出地道、安全 Rust 代码的关键。

作为经验丰富的 Java 开发者，我们对 Maven 的 pom.xml 和 Gradle 的 build.gradle 文件再熟悉不过了。它们是 Java 生态的基石，强大、成熟，但有时也……相当繁琐。冗长的 XML 配置、复杂的 Groovy/Kotlin 构建脚本、插件管理、以及时不时出现的“依赖地狱”，都是我们工作中习以为常的“痛点”。

现在，请深吸一口气，准备好体验一股清流。我们将认识 Cargo——Rust 的官方构建工具和包管理器。它不仅仅是一个工具，更是一位全能的项目管家，它的简洁、高效和一体化的设计，正是本章标题“秒杀”二字的底气所在。

作为一名资深的 Java 程序员，你的职业生涯中一定充满了与两类“幽灵”的斗争：一个是神出鬼没、导致程序崩溃的 NullPointerException（NPE）；另一个是繁琐的 try-catch-finally 结构以及它所代表的受检（Checked）与非受检（Unchecked）异常之争。

NullPointerException 被其发明者 Tony Hoare 称为“价值十亿美元的错误”。它是一个运行时错误，总是在你最意想不到的地方出现。Java 的异常系统虽然强大，但受检异常（如 IOException）常常污染方法签名，导致层层 throws；而非受检异常（RuntimeException）则像代码中的隐形地雷。

恭喜你，坚持到了这里。你已经征服了所有权（Ownership）和借用（Borrowing）。你现在理解了 Rust 如何通过 move 和 & 来保证内存安全。在前面的章节中，编译器似乎总能神奇地知道一个引用是否有效。

但有时，当引用关系变得复杂时，编译器也会“感到困惑”。这时，它就需要你的帮助。生命周期（Lifetimes） 就是你与编译器之间的一种“交流语言”，你用它来向编译器描述和证明你的引用是有效的。

在上一章的结尾，我们遇到了一个难题：如果我们只是想让一个函数读取一下数据，却不得不将数据的所有权交出去，用完后再由函数返还。这个过程就像是为了让朋友开一下你的车，却需要办理一次完整的车辆过户手续，开完后再给你过户回来一样，既笨拙又低效。

// 上一章的笨拙模式
fn calculate_length(s: String) -> (String, usize) {
    let length = s.len();
    (s, length)
}

这显然不是理想的编程方式。幸运的是，Rust 提供了一个优雅得多的解决方案，它就是借用（Borrowing）。

欢迎来到本专栏的“天王山之战”。到目前为止，我们学习的所有内容，都是在为理解本章的**所有权（Ownership）**系统做铺垫。这正是 Rust 能够做到“无需垃圾回收器（GC）的内存安全”的秘密所在，也是它与其他所有主流语言最根本的区别。

作为一名经验丰富的 Java 开发者，你可能已经很久没有真正地“关心”过内存了。我们使用 new 关键字创建对象，然后就心安理得地把它抛之脑后。JVM 中那个勤勤恳恳的垃圾回收器（GC）会帮我们处理好一切。这是一种奢侈，也是 Java 强大生产力的来源之一。

到目前为止，我们已经掌握了 Rust 的变量、数据类型和控制流。现在，我们将进入一个对 Java 开发者而言至关重要，也可能感到最“颠覆”的领域：代码的组织结构。

在 Java 的世界里，class（类）是我们思想的中心。它将数据（字段）和行为（方法）封装在一起，构成了我们所理解的“对象”。我们理所当然地认为，这是组织代码的唯一“正确”方式。

在前面几章，我们搭建了环境、理解了变量的可变性，并探索了 Rust 的数据类型。我们已经准备好了“食材”，现在是时候学习如何“烹饪”了——也就是如何根据这些数据来引导程序的执行路径。

你可能觉得 if、for 这些东西再熟悉不过了。但在 Rust 中，它们都藏着一个统一且强大的“新花样”，这个新花样是理解 Rust 编程范式的关键。这个核心思想就是：