1.2 搭建审判环境：工具链与Cargo
1.2 搭建审判环境：工具链与 Cargo
本节摘要：介绍 Rust 工具链的组成——rustup 管版本、rustc 管编译、Cargo 管工程——并给出安装、验证、升级与代理设置的完整操作序列。读完你可以独立搭好一套可用的开发环境，并知道每个工具在"法庭"里的职务。
工具链的职务表
Rust 官方安装器是 rustup，装完它，下面这套班子就齐了：
| 工具 | 职务 | 常用场景 |
|---|---|---|
| rustup | 工具链版本管家 | 安装、切换 stable 与 nightly |
| rustc | 编译器本体，也就是"法官" | 单文件快速试验 |
| cargo | 工程管家：建项目、装依赖、跑测试 | 日常 99% 的入口 |
| rustfmt | 代码格式化 | 统一风格 |
| clippy | 静态 lint，"法官助理" | 提前指出坏味道 |
安装与验证
Linux 与 macOS 下执行官方一键脚本；Windows 下运行官网提供的安装器。装完在终端验证：
rustc --version cargo --version rustup --version
三条都能出版本号即装好。国内网络环境下可给 cargo 配置镜像源，写入用户目录下 Cargo 的配置文件即可（字段名为注册表地址替换），这里不贴具体地址，官网文档有权威清单。
用 Cargo 开庭
cargo new first_case # 新建项目，含 git 初始化与 hello world cd first_case cargo run # 编译并运行 cargo build --release # 优化编译，产物在 release 目录 cargo check # 只查不编，最快看到"判词"
cargo check 值得单独点名：它跳过代码生成，只做类型与借用检查，速度常常快一个数量级。与借用检查器磨合期，把 check 挂进编辑器保存动作，判词几乎是即时出现的。
工具链切换
rustup update # 升级当前工具链 rustup toolchain install nightly cargo +nightly build # 临时用 nightly 编译
⚠️ 常见坑：直接 apt 类包管理器装的 rustc 常常严重过时，之后又用 rustup 装一份，两套混用导致"明明装了新版本还是旧的"。认准 rustup 一条渠道。
工具链解剖：rustup 管的是什么
rustup 管理的是"多套并行工具链"。同一台机器上可以同时存在 stable、nightly 和多个目标的交叉工具链，靠目录约定隔离，互不污染。
$ rustup show active toolchain stable-x86_64-pc-windows-msvc (default) rustc 1.79.0 (cached) installed toolchains stable-x86_64-pc-windows-msvc (default) nightly-2024-06-01-x86_64-pc-windows-msvc installed targets for active toolchain wasm32-unknown-unknown thumbv7em-none-eabihf
常用组件按职责分四类，排错时先确认组件在不在场：
| 组件 | 职责 | 何时用到 |
|---|---|---|
| rustc | 编译器本体 | 单文件速验语法 |
| cargo | 构建与包管理 | 日常九成的操作入口 |
| rustfmt | 统一格式 | 提交前自动排版 |
| clippy | 静态审查 | 找出"能编译但不地道"的写法 |
版本切换用 rustup override set nightly 只对当前目录生效，这对宏开发这类依赖夜间特性的项目很关键，不会波及机器上的其他案卷。
Cargo.toml 逐行取证
[package] name = "evidence" # 包名，也是外部引用时的凭证 version = "0.3.1" # 语义化版本：不兼容改动必须升主版本 edition = "2021" # 语言判例集版本，见下文 [dependencies] serde = { version = "1", features = ["derive"] } rand = "0.8" [profile.release] lto = true # 跨包链接期优化，发布二进制再开
版本串 "1" 等价于 >=1.0.0, <2.0.0，锁定到 Cargo.lock；features 是按需编译的开关，不用的代码根本不进产物。edition 不是编译器版本，而是判例集版本——2015 到 2018 把路径解析改了，2018 到 2021 把数组 into_iter 等语义改了，旧代码靠它保持原判不变。
构建档案室：target 目录
cargo build 之后值得进 target/debug 看一眼：依赖按名称哈希分目录存放中间产物，最终二进制在 target/debug 里。debug 与 release 是两套完整档案，优化等级、调试符号、断言开关全然不同——性能取证的基准必须在 release 档下做，否则结论不可采信。
常用指令的办公桌
| 指令 | 产出 | 使用频率 |
|---|---|---|
| cargo new / init | 新建项目骨架 | 每项目一次 |
| cargo check | 只查不编，秒级反馈 | 写代码期间的主力 |
| cargo build / run | 编译 / 编译并运行 | 阶段性验证 |
| cargo clippy | 静态审查建议 | 提交前 |
| cargo fmt | 统一格式 | 提交前 |
| cargo doc --open | 生成并打开文档 | 查依赖 API 时 |
cargo check 与 build 的差别值得单独点名：check 跳过代码生成，只跑前端检查，大项目上反馈时间差一个数量级。日常循环应当是 check 驱动开发，最终验证才 build 与 run。clippy 的建议等级不同，-D warnings 可以把警告升级为驳回，CI 里配成强制项，代码库的口味一致性就由机器看守了。
依赖检索与引入的规矩
引入一个新依赖前的三问：维护是否活跃、是否 hysteria 传递依赖、许可证是否兼容。检索先用本地方向感，再用 crates 门户核对下载量与最近发布时间。引入时版本写宽（"1"），锁定交给 Cargo.lock；发现传递依赖冲突时 cargo update -p 包名 --precise 版本 可以精确降级某一环，不必动全局。小项目随手加依赖的习惯要早戒：每个依赖都是长期负债，标准库与 core 能解决的不外求。