我是 Rust 新手，我刚刚通过 cargo new my_project 创建了一个新项目。我注意到 cargo 提供了这两个命令行选项：
我认为后者可用于编译我机器上的任何项目，而前者只能在当前工作目录中使用。那是对的吗？还有其他区别吗？运行两个不带额外参数的命令会得到完全相同的输出。
【问题讨论】：
rustc 命令。你安装了货物扩展吗？
cargo-edit。
cargo rustc 命令，但它只显示cargo --list，而不是cargo --help
标签： rust rust-cargo
为了更好地理解这些命令在高层次上的不同之处，我们可以比较这些命令的实现。所以我们首先将cargo repo 克隆为
git clone https://github.com/rust-lang/cargo.git
然后比较cargo build和cargo rustc的实现与
diff -u -w cargo/src/bin/cargo/commands/build.rs cargo/src/bin/cargo/commands/rustc.rs
由此不难看出cargo build和cargo rustc都是this内部cargo函数的薄包装：
pub fn compile<'a>(ws: &Workspace<'a>, options: &CompileOptions) -> CargoResult<Compilation<'a>> {
// ...
}
但在所公开的选项类型方面存在差异。事实上，您可以在cargo_compile.rs 顶部阅读定义该功能的这条评论：
//! This module contains the entry point for starting the compilation process
//! for commands like `build`, `test`, `doc`, `rustc`, etc.
换句话说，cargo build 和 cargo rustc 并不是围绕同一编译入口点的唯一瘦包装器。
那么，为什么货物背后的人会选择这样做呢？为什么不使用一个带有大量标志的 cargo compile 命令来完全公开底层实现？
显然，必须以一种对 Rust 生态系统的各种目标受众来说易于记录和理解的方式组织事物。
例如，Rust 生态系统的大多数新手都不想接触到调整编译器标志的可能性。因此，在开始时仅将它们公开给cargo build 及其文档是有意义的，具有其特殊的编译选项风格。
一旦他们成为更高级的用户，他们会发现使用cargo rustc 可以对编译过程产生更详细的影响。
【讨论】：
工作目录没有区别。不同之处在于如何将编译器选项传递给rustc，其中许多 Cargo 不知道/公开：
cargo build [OPTIONS]：如果你想传递一个标志给rustc，一般你不能在命令行上这样做，你需要use the RUSTFLAGS variable or edit config files。
cargo rustc [OPTIONS] [-- ARGS]：可用的OPTIONS 与cargo build 大致相同，但参数传递给rustc。所以你可以写cargo rustc --release -- -C overflow-checks=yes。
【讨论】：
cargo build 只是cargo rustc 的一个功能较弱的版本，与cargo build 一起使用的所有内容都可以与cargo build 一起使用。
在这个 issue 和 pull request 中添加了它：
据我了解，添加它是为了能够传递编译器参数来构建。它主要用于调试目的。
【讨论】：
cargo build、test 和 run 的新参数？
cargo rustc 与 rustc 本身具有相同的参数，但 cargo build 无法添加其中一些参数，因为它们与旧键重叠。如果他们改变了build 参数的含义，则会导致不好的破损。 AFAIK，cargo build 出现早于 cargo rustc。