我是 Rust 的新手，我刚刚通过cargo new my_project. 我注意到cargo 提供了这两个命令行选项：
我认为后者可用于编译我机器上的任何项目，而前者只能在当前工作目录中使用。那是对的吗？还有其他区别吗？不带附加参数运行这两个命令会给我完全相同的输出。
工作目录没有区别。区别在于如何将编译器选项传递给rustc，其中许多选项 Cargo 不知道/公开：
cargo build [OPTIONS]：如果你想传递一个标志rustc，通常你不能在命令行上这样做，你需要使用RUSTFLAGS变量或编辑配置文件。
cargo rustc [OPTIONS] [-- ARGS]：OPTIONS可用的内容或多或少与 for 相同cargo build，但参数被传递给rustc. 所以你可以例如写cargo rustc --release -- -C overflow-checks=yes.
为了更好地掌握命令的不同之处，我们可以比较命令的实现。所以，我们首先克隆cargo 回购与
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都是围绕这个内部货物功能的薄包装：
git clone https://github.com/rust-lang/cargo.git
但在暴露的选项类型上有所不同。事实上，人们可以在cargo_compile.rs定义该函数的顶部阅读此注释：
diff -u -w cargo/src/bin/cargo/commands/build.rs cargo/src/bin/cargo/commands/rustc.rs
换句话说，cargo build并且cargo rustc不是围绕同一编译入口点的唯一瘦包装器。
那么，为什么cargo背后的人会选择这样做呢？为什么不用一个cargo compile带有大量标志的单个命令来完全公开底层实现？
显然，它必须以易于记录和理解 Rust 生态系统的各种目标受众的方式组织事物。
例如，大多数 Rust 生态系统的新手都不想接触到调整编译器标志的可能性。因此cargo build，在开始时仅将它们及其文档及其特定的编译选项公开是有意义的。
一旦他们成为更高级的用户，他们就会发现使用cargo rustc.