有时你会遇到一个旧项目，必须用特定版本的 Rust 才能编译，或者某个第三方 crate 对 rustc 版本有严格限制。如果直接装最新版，编译可能报错，依赖冲突处理起来很麻烦。这时候就需要一套能安装、切换、甚至单独卸载某个工具链的方法。下面是我在处理这类问题时常用的操作方式，每一步都尽量说清楚适用场景和验证方法。

使用 Rust 官方推荐的 rustup 工具时，安装特定版本最简单的方式是执行 `rustup install 版本号`，例如 `rustup install 1.65.0`。该命令会自动下载并安装对应版本的 Rust 编译器与标准库，不会影响系统上已有的其他版本。安装完成后，可通过 `rustup show` 查看当前所有已安装的版本列表。

如果需要将某个特定版本设为默认工具链，运行 `rustup default 版本号`，例如 `rustup default stable` 会使用最新稳定版，而 `rustup default nightly` 则切换到每日构建版。注意切换默认版本后，后续所有新项目都会默认使用该版本，除非在项目目录中通过 `rustup override` 单独指定。

一、通过 rustup 安装特定版本

使用 Rust 官方推荐的 rustup 工具时，安装特定版本最简单的方式是执行 rustup install 版本号，例如 rustup install 1.65.0。该命令会自动下载并安装对应版本的 Rust 编译器与标准库，不会影响系统上已有的其他版本。安装完成后，可通过 rustup show 查看当前所有已安装的版本列表。

如果你第一次安装 Rust，通常建议先用 rustup-init 安装 rustup，然后重复执行上面的 install 命令就能添加任意版本。这里有个需要注意的地方：安装旧版本时，rustup 会拉取当时的源代码和组件，如果网络不稳定可以预先设置镜像源，否则可能超时。任何版本安装成功后，你都可以随时通过 rustup toolchain list 确认它已出现在列表中。

二、设置默认工具链与项目覆盖

如果需要将某个特定版本设为默认工具链，运行 rustup default 版本号，例如 rustup default stable 会使用最新稳定版，而 rustup default nightly 则切换到每日构建版。注意切换默认版本后，后续所有新项目都会默认使用该版本，除非在项目目录中通过 rustup override 单独指定。

在实际项目中，我更常用的是 rustup override set 来临时覆盖某个目录的版本。比如在一个遗留项目根目录执行 rustup override set 1.65.0，之后在此目录下执行所有 cargo 命令都会用 1.65.0 而非全局默认。这个覆盖优先级高于 rustup default，也高于 rust-toolchain.toml 文件。如果你想让项目彻底绑定版本，推荐在根目录创建 rust-toolchain.toml 文件，写入 [toolchain] 节并指定 channel，这样团队成员都能自动采用同一版本。

三、验证当前生效的版本

要验证当前生效的 Rust 版本，可以在终端中输入 rustc --version 或 cargo --version。如果系统安装了多个版本且通过 rustup 管理，rustup toolchain list 会列出所有已安装的工具链并标注当前默认项。当项目根目录存在名为 rust-toolchain.toml 或 rust-toolchain 的文件时，实际使用的版本由该文件决定而非全局默认值。

这时如果你发现 rustc --version 输出的版本跟你预期的不一致，可以先检查当前目录下是否存在这两个文件。我遇到过几次因为同事误提交了 rust-toolchain 文件导致 CI 与本地版本不一致的情况。排查思路是：先看文件内容，再看 rustup show 输出的 active toolchain。如果同时存在 rustup override 和 rust-toolchain，override 优先级更高。如果找不到任何覆盖，则全局默认 version 生效。

四、安装旧版本的风险与 MSRV 检查

安装旧版本时需注意可能缺少某些新版本特性或存在已知的安全漏洞。例如，Rust 1.29 之前的版本不支持 cargo check 命令，而 1.64 之前的版本可能缺少对某些平台架构的完整支持。如果需要使用基于特定版本号的 crate，请务必检查该 crate 的文档中声明的 MSRV（最低支持的 Rust 版本），否则可能出现编译错误。

实际操作中，我一般会在项目的 Cargo.toml 里看 package.rust-version 字段，或者去 crate 的文档页找 MSRV 标识。如果 crate 没有明确指定，可以尝试在依赖中加上 rust-version = "1.65" 让 cargo 自动检查。如果编译中途报错“只支持较新版本”，那就要降低依赖版本或升级 rustc，不要硬撑。

对于安全补丁，Rust 团队只维护最近几个稳定版。如果因为项目原因必须用极旧的版本（比如 1.35.0），建议在独立的隔离环境中运行，并定期评估升级的可能性。

五、Nightly 版本的固定与警惕

对于 nightly 版本，其 API 可能随时变动，且部分特性仅在特定版本后可用。例如，使用 #![feature] 属性的 unstable 功能可能只在某个 nightly 区间内有效，若直接升级可能导致代码无法编译。建议在 CI 流水线中固定 nightly 版本的精确日期（如 nightly-2023-06-01）而非仅用 nightly，以避免每日构建的意外破坏。

你可以在本地用 rustup toolchain install nightly-2023-06-01 来指定某一天的构建，然后通过 rustup override set nightly-2023-06-01 锁定。在 Cargo.toml 里也可以写 toolchain.channel = "nightly-2023-06-01"。如果哪天需要升级，手动改日期并测试所有 feature。记住，nightly 没有向后兼容承诺，即使只差一天也可能编译失败。

六、卸载不再需要的版本

当不再需要某个特定版本时，可以通过 rustup toolchain remove 版本号 将其卸载，例如 rustup toolchain remove 1.62.0。注意，卸载当前默认工具链前需要先切换至其他版本，否则 rustup 会提示错误。此外，rustup 本身不会自动清理下载的缓存文件，如需释放磁盘空间可手动删除 ~/.rustup/downloads 目录下的临时文件。

我一般每隔几个月检查一次 rustup toolchain list，把不再使用的旧版本删掉。删除前记得确认没有项目依赖该版本。如果某个版本被删后又需要，重新 rustup install 就行。另外，~/.rustup/toolchains 目录下每个版本占用几百 MB，清理 downloads 目录能多释放一些，但只是临时下载包，不影响已装工具链。

以上就是我处理 Rust 特定版本工具链的完整流程。每个步骤都有对应的验证方法和风险边界，建议在实际安装前先列清楚项目要求的版本号，然后逐个操作确认。如果遇到编译错误，优先检查 rustup show 的 active toolchain 是否是你预期的那一个。