Rust: main.rs 和 lib.rs — 如何避免模块混淆并加速代码

Rust 模块混淆：main.rs 和 lib.rs 如何让人抓狂（以及如何修复）

你是否曾经在编写 Rust 代码时，创建了一个新项目，添加了 main.rs 和 lib.rs，然后编译器突然开始报出一些看似毫无意义的错误？很熟悉吧？如果你曾在谷歌上搜索过“当存在 main.rs 和 lib.rs 时的 Rust 模块混淆”，那么你并不孤单。这个问题在 Stack Overflow 上已经获得了数千次浏览，这并非没有原因。模块混淆是新手（甚至是刚从其他语言转过来的经验丰富的开发者）最常遇到的问题之一。

在本文中，我们不仅会解析 Rust 模块系统的工作原理。我们还将展示，正确的模块组织方式如何直接影响你代码的优化和性能。你将了解到为什么 lib.rs 不仅仅是“另一个文件”，而是一个用于加速编译和创建清晰 API 的强大工具。让我们开始吧！

问题：“为什么编译器看不到我的模块？”

想象一下：你使用 cargo new my_project 创建了一个项目 my_project。默认情况下，Cargo 会创建 src/main.rs。你添加了第二个文件——src/lib.rs——并在其中编写了一个函数。然后你尝试从 main.rs 中调用它——结果却得到了一个错误：

error[E0432]: unresolved import `my_project::some_function`\n --> src/main.rs:1:5\n  |\n1 | use my_project::some_function;\n  |     ^^^^^^^^^^^^^^^^^^^^^^^^^ no `some_function` in the root

是不是很熟悉的痛？问题出在哪里？很简单：Rust 将 main.rs 和 lib.rs 视为两个不同的 crate 根。如果在 Cargo.toml 中没有特别指定，Cargo 会自动创建两个 crate：一个二进制 crate（来自 main.rs）和一个库 crate（来自 lib.rs）。除非你明确指定依赖关系，否则它们不会直接“看到”对方。

这就是大家常说的Rust 模块混淆。但是，与其生气，不如让我们把这个“特性”变成一个优势。

解决方案：如何正确组织模块

有两种方法，选择取决于你的目标。但我们先剧透一下：第二种方法——对性能更有利。

方案 1：所有内容放在一个 crate 中（简单，但不可扩展）

如果你的项目很小，你可以使用 mod 在 main.rs 内部声明模块：

// src/main.rs\nmod utils; // 查找 src/utils.rs 或 src/utils/mod.rs\n\nfn main() {\n    utils::do_something();\n}

这行得通，但如果你添加了 lib.rs，混乱就会开始。lib.rs 会成为一个独立的 crate，而 main.rs 中的模块将无法在其中使用。对于小型脚本来说可以，但对于严肃的项目来说不行。

方案 2：库 + 二进制文件（优化的正确路径）

最合理的方式是让 lib.rs 成为逻辑的主要存储库，而 main.rs 则作为启动的薄包装层。这样你可以获得：

\n
• 模块化：所有业务逻辑都在库中。
\n
• 可测试性：库可以单独进行测试。
\n
• 性能：如果库代码被多次使用，编译器可以更好地优化它。
\n

如何实现？很简单：

// src/lib.rs\npub mod utils;\n\npub fn run() {\n    utils::do_something();\n}\n\n// src/main.rs\nfn main() {\n    my_project::run(); // my_project 是来自 Cargo.toml 的 crate 名称\n}

请注意：main.rs 现在使用了 my_project::run()。这之所以有效，是因为 Cargo 将 lib.rs 视为名为 my_project 的库。瞧——混乱消失了！

优化与性能：为什么 lib.rs 是你的朋友

现在最有趣的部