在 Windows 上装 Rust，看起来是件小事：下载一个安装包，双击，一路回车，结束。但我带过的新人里，十个有六个卡住的不是这一步——rustup 本身几乎是傻瓜式的，真正让人原地打转的是它背后那个链接器。rustc 打印版本号打印得挺开心，cargo run一敲，屏幕甩出一行error: linker 'link.exe' not found，然后就不知道往哪走了。还有人装完发现终端里cargo命令认识，换一个终端窗口就不认识了，重启电脑才好；也有人折腾一下午，最后发现是路径里带了个中文目录。

这篇东西就是把我自己在 Windows 上做windows 安装 rust这件事的完整流程、踩过的坑、以及后面那些“装完才算开始”的配置，一次讲透。核心围绕三样东西：rustup 版本管理器、工具链（MSVC 或 GNU）、以及链接器与系统依赖。看完你应该能做到：从一台干净的 Windows 机器出发，装好一套能正常编译、能跑测试、能装第三方 crate 的环境，并且知道每个选项为什么这么选。

适合谁看？完全没碰过 Rust 的新手，可以照着抄；从其他语言转过来、被链接错误劝退过一次的，可以跳过前面看排查部分；已经装好了但总觉得编译慢、依赖拉不下来的，直接看镜像和提速那两节。我不打算写成一板一眼的说明书，就把我实际操作时的顺序和判断依据摆出来。

1. 装之前先搞清楚：Windows 上的 Rust 到底由什么组成

很多人对“安装 Rust”的理解是“装一个叫 Rust 的软件”，这个心智模型从一开始就错了，后面所有的困惑都从这儿长出来。Rust 不是单个可执行文件，它是一套由版本管理器托管的、可以多版本共存的工具集合。你在命令行敲的rustc、cargo、rustfmt、clippy，本质上都是被 rustup 放进 PATH 里的转发器（shim），真正的二进制文件躺在另一个带版本号的目录里。

1.1 rustup、工具链、链接器：三个角色别搞混

我把这三者的关系类比成“游戏启动器 + 游戏本体 + 显卡驱动”。rustup 是启动器，负责下载、切换、更新；工具链（toolchain）是游戏本体，一个工具链就是一套完整的rustc + cargo + 标准库，名字长这样：stable-x86_64-pc-windows-msvc，拆开读是「发布通道 - 架构 - 操作系统 - ABI」；链接器是显卡驱动，负责把编译出来的中间产物拼成最终的.exe，它不属于 Rust，而是来自 C++ 的编译环境。

这个划分为什么重要？因为 90% 的安装失败都发生在第三个角色上。rustup 装工具链这一步极少出问题，出问题的是“工具链找不到链接器”。所以正确的安装顺序不是“先装 Rust 再说”，而是先把链接器准备好，再装 Rust，让它在安装时就能自检通过。

1.2 MSVC 与 GNU 两条路，选错了后面全是坑

Windows 上官方提供两种 ABI 的工具链，安装包也分两个：

新手看到 GNU 版本“不用装额外东西”就想选它，这个诱惑我理解，但我不建议。原因很实际：你迟早会引入某个带 C 依赖的 crate，一旦它在 GNU 链路上报cannot find -lgcc_s这类错误，排查成本远超你省下来的那 3 GB 磁盘。MSVC 是官方主推路径，生态里的默认假设就是它，走人多的路，出问题时能搜到的答案也多。

提示：已经装了 GNU 工具链也不必重装整个环境，后面第 7 节讲怎么用 rustup 补装并切换，两条链路可以共存。

1.3 磁盘空间和权限，先算清楚再动手

给个实际数字：Visual Studio 生成工具勾选 C++ 桌面开发后，安装完大约占 2.5 到 4 GB（含 Windows SDK），Rust 工具链本身（stable，default profile）约 1.2 GB，加上~/.cargo里的依赖缓存，一个能正常干活的环境预留 8 GB 比较稳妥。如果你的系统盘常年飘红，可以走第 4 节的环境变量搬家方案，把CARGO_HOME和RUSTUP_HOME指到别的盘。

权限方面，安装生成工具需要管理员权限，装 rustup 不需要——rustup 默认装到用户目录，这是好事，避免了全局污染。但要注意一种情况：如果公司电脑做了策略限制，用户目录被重定向到网络盘，编译速度会慢到无法忍受，这时候要么跟 IT 沟通，要么老老实实改CARGO_HOME。

2. 先把底座搭稳：生成工具与系统环境准备

这一节是整篇文章最不酷但最值钱的部分。我的习惯是：在跑任何 Rust 安装程序之前，先把 C++ 编译环境装好、验证通过，再去装 Rust。顺序反过来也能成，但你会在 rustup 的最后一步看到一个黄色的警告，然后开始怀疑人生。

2.1 生成工具的组件勾选，多一个少一个都不行

去官方站点下载「生成工具」安装器（注意不是完整的 IDE，我们只要编译能力）。运行后进入工作负载界面，勾选使用 C++ 的桌面开发。勾完之后右侧的详细信息里会自动带上一堆组件，其中这两项是关键：

• MSVC v143 生成工具（x64/x86 最新版）：提供link.exe、cl.exe、lib.exe，这是 Rust 编译的最后一步必需的东西。
• Windows 10/11 SDK：提供系统库的导入库（.lib）和头文件。少了它，链接阶段会报一堆LNK1104 无法打开文件 'kernel32.lib'之类的错误。

其余的比如 CMake、测试工具、诊断工具，可以按需砍掉，能省一两个 G。但不要手动取消 MSVC 生成工具或 SDK——我见过有人为了省空间只勾了个“C++ 核心功能”，结果 rustup 检测通过、编译却报错，因为检测逻辑只看link.exe在不在，不看你 SDK 全不全。

安装完成后验证一下，打开普通命令提示符（不用管理员）：

where link

如果输出为空，别急着怀疑人生，可能只是 PATH 还没生效。生成工具的link.exe通常不会加入全局 PATH，Rust 是通过注册表和环境变量定位它的。更靠谱的验证方式是直接找文件：

dir "C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Tools\MSVC"

能看到带版本号的目录（比如14.4x.xxxxx）就说明 VC 工具装上了。这一步过了，后面的路就顺了。

2.2 路径、编码、杀软：三个容易被忽略的前置条件

路径里不要有中文和空格。这一条在 2024 年之后已经宽松很多，cargo对 Unicode 路径的处理基本没问题，但第三方构建脚本（build.rs调用外部工具的那些）仍然时不时翻车。最省心的做法是：如果你的 Windows 用户名是中文，比如C:\Users\张三，强烈建议直接把CARGO_HOME和RUSTUP_HOME改到D:\rust\cargo和D:\rust\rustup这类纯 ASCII 路径下。这个改动五分钟，能省掉未来无数个“为什么只有这个 crate 编译不过”的深夜。

控制台编码。默认的代码页是 GBK，cargo build的输出里一旦有非 ASCII 字符（比如某些 crate 的构建脚本输出）就会显示成乱码，虽然不影响编译结果，但排查错误时很误导。可以临时用chcp 65001切到 UTF-8，或者在 Windows 终端的设置里把默认编码改成 UTF-8。

杀毒软件的实时防护。Rust 编译会产生大量小文件，target目录动辄几万个文件，实时扫描会让编译时间翻倍甚至更多。我的做法是把项目目录和CARGO_HOME加入排除列表。另外偶尔会出现link.exe被杀软拦截导致编译中断的情况，症状是编译到链接阶段突然报“拒绝访问”，这种时候去防护日志里翻一下就能确认。

2.3 环境变量搬家：给系统盘减负的正确姿势

想把 Rust 的家目录挪走，在装 rustup之前设置好两个用户环境变量即可，顺序很重要：

setx CARGO_HOME "D:\rust\cargo" setx RUSTUP_HOME "D:\rust\rustup"

setx写的是用户级持久变量，写完要开新终端才生效。这两个变量的分工是：RUSTUP_HOME存工具链本体（每个版本一个子目录），CARGO_HOME存 cargo 自己的二进制、crate 缓存、以及后面的配置文件。RUSTUP_HOME体积大且只增不减，CARGO_HOME里的 registry 缓存可以用cargo cache之类的工具清理，分开放在不同磁盘上也是一种思路。

注意：如果已经装过 rustup 再改这两个变量，等于把家目录“搬走”，旧目录里的工具链不会被自动迁移，你得把整个目录手动复制过去，或者干脆卸了重装。我一般建议在干净的机器上一次到位。

3. rustup 安装实操：菜单里每一项到底在问什么

环境准备好，终于可以跑安装程序了。官方页面会给你两个下载链接，选x86_64-pc-windows-msvc那个（除非你明确要走 GNU）。文件叫rustup-init.exe，只有几 MB，双击运行会弹出一个黑框，先是欢迎语，然后是一段很长的英文说明，最后停在三个选项上。

3.1 三个选项，选 1 还是选 2

菜单长这样：

1) Proceed with installation (default) 2) Customize installation 3) Cancel installation

绝大多数教程让你直接按 1。我的建议是第一次装的人按2，花两分钟看一眼默认值，尤其是下面这几项：

• Default host triple：默认x86_64-pc-windows-msvc。如果你下载错了安装包（比如下成了 GNU 版），这里会显示-gnu，这时候退出去重下比硬装要好。
• Default toolchain：默认stable。别选 nightly，除非你在做需要不稳定特性的实验；nightly 的编译产物和 stable 不兼容，混用会浪费大量时间。
• Profile：默认default，包含rustc、cargo、rust-std、rust-docs、rustfmt、clippy。选minimal只装rustc和cargo，体积小一半但没有 clippy 和 rustfmt，我一般会在装完后手动补这两个组件，所以其实default更省事。complete会带上源码和更多文档，多占一两个 G。
• Modify PATH variable?：默认Yes。这一项务必保持 Yes，它会把%CARGO_HOME%\bin加进用户 PATH。选 No 的话你得自己加，忘了就是“cargo 不是内部或外部命令”。

看完按回车回到主菜单，再按 1 开始安装。下载过程从几十秒到几分钟不等，取决于网络状况。如果卡在info: downloading component 'rust-std'十几分钟不动，多半是网络问题，Ctrl+C 中断重跑就行，rustup 支持断点续传。

3.2 装完后的自检清单

安装程序最后会打印一行Rust is installed now. Great!。关掉当前终端，重新开一个——这是新手最常忽略的一步，PATH 的修改不会传染给已经开着的窗口。然后逐条跑：

rustc --version cargo --version rustup --version rustup show

前三条出不来，说明 PATH 没生效，检查echo %PATH%里有没有\.cargo\bin。rustup show的输出信息量最大，它告诉你当前默认工具链、已安装的工具链列表、以及当前目录生效的是哪个（如果你在某个带rust-toolchain.toml的项目里，这里会显示被覆盖的版本）。

再补两个组件，未来会天天用到：

rustup component add clippy rustfmt

clippy是代码检查工具，能在编译前抓出一堆写法问题；rustfmt负责格式化。这两个东西加上编辑器插件，是 Rust 开发体验的核心。

3.3 目录结构长什么样，为什么值得看一眼

装完之后，RUSTUP_HOME下面的结构大致是这样：

D:\rust\rustup\ ├── downloads\ # 安装包缓存，可以放心删 ├── settings.toml # 全局配置，记录了默认工具链 ├── toolchains\ │ └── stable-x86_64-pc-windows-msvc\ │ ├── bin\ # rustc.exe、cargo.exe 的真实位置 │ └── lib\rustlib\ └── update-hashes\

而CARGO_HOME里是bin\（shim 转发器）、registry\（拉下来的 crate 源码和索引缓存）、config.toml（下一节的主角）。理解这个结构有个实际好处：当你遇到“编译出来的东西和想象不一致”时，可以直接去toolchains\<版本>\bin下确认二进制是不是你以为的那个版本。我遇到过一次rustc --version显示 1.75，但某个项目死活编译不过，最后发现那个项目里有rust-toolchain.toml钉了 1.68，rustup 自动装了第二个工具链——rustup show一眼就看到了。

4. 让 cargo 顺手起来：镜像、缓存与编译提速

安装完成到能舒心干活之间，还隔着一段配置。核心目的就两个：让依赖下得动，让编译快得起。这两件事在 Windows 上比在别的系统上更值得调，因为默认的单线程链接和目录结构与杀毒软件的交互会让编译明显变慢。

4.1 配置 crate 索引镜像，别让拉依赖变成等待游戏

默认情况下cargo build会去官方索引拉取 crate 元数据和包体。国内网络环境下这一步的体验取决于时段，有时几秒，有时几分钟。配置镜像能明显改善，做法是编辑%CARGO_HOME%\config.toml（没有就新建）：

# %USERPROFILE%\.cargo\config.toml [source.crates-io] replace-with = "mirror" [source.mirror] registry = "sparse+https://<镜像站提供的 sparse 索引地址>/" [net] git-fetch-with-cli = true

三个地方需要解释。第一，replace-with是替换不是“备用”，配错了会导致所有依赖都拉不到，所以填地址时务必确认镜像站给的是 sparse 索引地址（以sparse+开头），而不是老的 git 索引地址。第二，sparse协议从 cargo 1.70 起是默认，它按需请求单个 crate 的元数据，比一次性克隆整个索引快一个数量级，如果你的 cargo 版本较老，先rustup update再说。第三，git-fetch-with-cli = true让 cargo 在遇到 git 依赖时调用系统的 git 命令，而不是内置的 libgit2，这两年内置实现在某些网络环境下握手失败的情况时有发生，交给系统 git 更稳。

提示：镜像站地址各家给的形式不一样，有的要求带尾部斜杠，有的不需要。填完跑一次cargo new demo && cd demo && cargo build，如果能在十几秒内把依赖元数据拉下来，就说明配对了。要是报failed to fetch或者no matching package，先把这段配置整个注释掉，测试是不是镜像配错导致的，这一步能省掉大量误判。

4.2 编译提速：几个真正见效的开关

Windows 上 Rust 编译慢，主要慢在链接和文件 IO 上。下面几个做法我实测有效，按收益排序：

• 把项目放 SSD，且排除杀软扫描。收益最大，尤其是第一次全量编译。
• 调高并行度。cargo 默认按逻辑核心数分配任务，但链接阶段是单线程的。如果你的机器核多内存小，反而会因为并行过度导致换页。可以在配置里限一下：[build] jobs = 8。
• 开发时降级优化等级。[profile.dev]默认opt-level = 0，如果你想让它跑得快一点（比如跑集成测试），设成 1 或 2 通常能在编译时间增加不多的情况下大幅提升运行时性能。
• 减少 debug 信息。[profile.dev] debug = 1（默认是 2，完整调试信息），能显著减小target目录体积和链接时间。日常开发用 1 足够定位问题。
• 统一 target 目录。多个项目共用一个CARGO_TARGET_DIR可以复用依赖编译产物，缺点是并发编译时会锁竞争。我一般只在一个 workspace 内部共享，不跨项目全局设置。

一份我常用的config.toml组合：

[build] jobs = 8 [profile.dev] debug = 1 incremental = true [profile.dev.package."*"] opt-level = 2

最后那一段的意思是：你自己写的代码不优化，所有依赖按 2 级优化编译。这是社区里流传很广的一个技巧，因为运行时热点通常在依赖库里（比如解析、加密、序列化），把它们优化了，你的代码迭代速度不受影响，程序跑起来却快很多。

4.3 编辑器与语言服务器，别装重复的插件

编辑器我推荐 VS Code 加rust-analyzer扩展，这是目前最成熟的组合。有两个细节值得说：第一，只装 rust-analyzer 一个 Rust 相关扩展，把早年的 Rust 官方扩展和其他 RLS 时代的插件全卸了，它们会抢同一个语言服务器进程，导致补全时好时坏。第二，在设置里把保存时的检查从cargo check换成clippy：

{ "rust-analyzer.check.command": "clippy", "rust-analyzer.cargo.targetDir": true }

cargo.targetDir: true的作用是让 rust-analyzer 编译到独立的 target 目录，避免和你手动cargo build抢锁——不开这个，你会经常看到“正在等待文件锁定”的提示。

语言服务器第一次启动会做一次全量索引，CPU 占满几分钟是正常的，索引存在目标目录里，之后启动就快了。如果你打开一个刚克隆的项目发现补全全无、满屏红波浪线，八成是索引还没跑完或者依赖没拉下来，看一眼右下角的状态就知道了。

5. 第一个工程：从 cargo new 到 release 打包

到这里环境就算齐了。我坚持认为第一个工程不要用rustc main.rs手动编译，直接上 cargo，因为它会把目录结构、依赖管理、构建配置一次性摆给你看，等于免费上了一课。

5.1 目录结构与 Cargo.toml 的每个字段

cargo new hello_rust cd hello_rust

生成了两个东西：src/main.rs和Cargo.toml。前者是入口，后者是清单文件。清单里默认只有四行：

[package] name = "hello_rust" version = "0.1.0" edition = "2021"

edition值得单独讲一句。它不是 Rust 编译器版本，而是语言规则的快照，2021 edition 意味着这套代码按 2021 年的语法规则解析。它和工具链版本解耦，你用最新的 stable 编译器照样能编译 2015 edition 的老项目。新建项目时 cargo 会自动填当前推荐的 edition，不用手改，但看到别人的项目写edition = "2018"时别以为是版本太老要升级——随意改动可能引入破坏性变更。

目录里还有一个.gitignore和自动初始化的 git 仓库（cargo new默认会git init，加--vcs none可以跳过）。target/目录在第一次编译后才出现，务必确认它在.gitignore里，不然仓库体积会爆炸。

5.2 跑起来，然后看 release 模式的差别

cargo run # 编译 + 运行（debug） cargo build # 只编译 cargo build --release cargo check # 只做类型检查，不生成二进制，最快

cargo check是我日常用得最多的命令，改完代码先 check 一遍，比 build 快好几倍，语法和类型错误在这一步就能抓干净，确认没问题再 build。

debug 和 release 的差异比很多人想的大：release 开启 3 级优化、关闭调试断言、开启 LTO 的可选配置，一个计算密集的小程序两者性能差十倍都不稀奇。但 release 编译也慢得多，所以开发期间老老实实用 debug，交付前再--release。

产物在target\debug\hello_rust.exe和target\release\hello_rust.exe。这个 exe 可以直接拷到其他 Windows 机器上跑，前提是对方有 VC++ 运行时——绝大多数装过日常软件的机器都有，如果没有，症状是双击闪退或者报缺少VCRUNTIME140.dll。

5.3 加一个依赖，验证镜像和构建链路是通的

空项目跑通不算数，加个真实依赖才能验证第 4 节的配置生效了：

cargo add serde --features derive cargo add serde_json cargo build

cargo add是 cargo 1.62 之后内置的命令，不用再装cargo-edit。执行后Cargo.toml里会多出[dependencies]段，版本号写成serde = { version = "1", features = ["derive"] }这种形式。构建过程中你能看到Compiling、Downloaded、Downloading的输出，这一步如果很快完成，说明镜像配置成功；如果卡在Updating crates.io index很久，回到 4.1 检查配置。

顺带提一个 Windows 特有的东西。如果你写的是 GUI 程序，debug 模式下运行时背后会弹出控制台黑窗。加一行属性就能去掉：

#![windows_subsystem = "windows"]

但注意这行只在 release 下生效比较合适，debug 时保留控制台方便看println!和 panic 信息，所以我一般配合条件编译：

#![cfg_attr(not(debug_assertions), windows_subsystem = "windows")]

这样 debug 有黑窗方便调试，release 自动隐藏，一行代码解决。

6. 报错排查实录：那些让人抓狂的错误信息

前面流程走得顺，这一节你可以跳过。但根据我的观察，第一次在 Windows 装 Rust 的人，八成会在这里停下。我把遇到过的、以及帮别人解决过的典型问题整理成表，再挑几个展开讲讲排查思路。

6.1 常见报错速查表

6.2 三个典型故障的完整排查路径

第一个：link.exe 找不到，但你确信装了生成工具。这种情况我遇到过两次，原因完全不同。一次是装的是旧版生成工具，rustup 探测逻辑认不出它的路径；另一次是装了完整 IDE 但没勾 C++ 工作负载，只有 IDE 壳子没有编译器。排查顺序是：先rustup show确认当前工具链是-msvc结尾；再手动去C:\Program Files (x86)\Microsoft Visual Studio\2022\下看有没有BuildTools或Community目录，进去找VC\Tools\MSVC\<版本>\bin\Hostx64\x64\link.exe；文件在但 rustc 找不到，就启动“x64 Native Tools 命令提示符”再跑cargo build，这个环境预置了所有路径变量，能编译通过就说明是全局环境探测的问题。终极解法是重装生成工具并确保勾选完整。

第二个：换了个终端 cargo 就没了。症状很明确：在 VS Code 的集成终端里能用，在系统自带的 cmd 里不能用，或者反过来。原因是 PATH 修改只对新启动的进程生效，而 VS Code 如果是在改 PATH 之前打开的，它的集成终端继承的是旧环境。解决方式是彻底退出 VS Code（不是关窗口，是从任务栏退出），重新打开。还有一种可能是装的时候在 “Modify PATH” 那一步选了 No，那就手动加：用户变量 PATH 里追加%USERPROFILE%\.cargo\bin。

第三个：某个 crate 死活编译不过，报构建脚本失败。这类问题最难查，因为错误信息通常在build.rs的输出里，被 cargo 折叠了。技巧是加-vv看完整输出：cargo build -vv。我遇到的一次是路径里有中文字符导致某个 C 库的构建脚本传参失败，把CARGO_HOME挪到纯 ASCII 路径后解决；另一次是缺少某个系统库对应的.lib，需要在生成工具里补装对应版本的 SDK。判断方法很简单：把项目复制到一个路径为D:\tmp\test的纯英文短路径下再编译一次，能过就是路径问题，不能过再往下查依赖。

提示：任何时候看到note: run with RUST_BACKTRACE=1 environment variable to display a backtrace，别忽略它。设上这个变量再跑一次，调用栈会直接把 panic 的位置打出来，比盯着错误摘要猜半天有效得多。PowerShell 里就是$env:RUST_BACKTRACE=1，cmd 里是set RUST_BACKTRACE=1。

7. 工具链管理：多版本共存、切换与干净卸载

装好只是开始，长期用下去必然会遇到“这个项目要旧版本”“我想试试 nightly 的新特性”这类需求。rustup 在这方面做得相当好，理解它的几个命令能省下大量重装时间。

7.1 版本切换的三种粒度

按影响范围从小到大：

• 全局默认：rustup default stable，改的是settings.toml里的默认值，影响所有没被覆盖的目录。
• 按目录覆盖：rustup override set 1.75.0，在当前目录下写入一个覆盖记录，只对这个项目生效。适合临时接手老项目。
• 按项目声明：在项目根目录放一个rust-toolchain.toml：

[toolchain] channel = "1.75.0" components = ["rustfmt", "clippy"] targets = ["x86_64-pc-windows-msvc"]

第三种是团队协作的正解，把工具链版本写进仓库，谁拉下来都自动用同一个版本，rustup 发现缺失会提示安装。这解决了一个很烦的问题：不同版本编译器对同一个 crate 的编译结果可能不同，线上环境和本地不一致时，工具链版本不一致是常见元凶。

日常维护用这几条：

rustup update # 更新所有已安装的工具链 rustup toolchain list # 看装了哪些 rustup component list --installed # 看当前工具链装了哪些组件 rustup target add x86_64-pc-windows-gnu # 加交叉编译目标 rustup self update # 更新 rustup 自身

rustup update我一般一周跑一次，stable 通道每六周发一个大版本，中间的补丁版本主要是修 bug 和安全问题，保持更新是划算的。但不要在交付前夜更新，新版本偶尔会引入新的 lint 警告，#![deny(warnings)]的项目会直接编译失败。

7.2 卸载与重装：什么时候该推倒重来

卸载很简单，一条命令：

rustup self uninstall

它会删掉RUSTUP_HOME和CARGO_HOME，并从 PATH 里移除对应条目。但有几个残留值得注意：项目里的target目录不会删（这是对的，那是你的构建产物），Cargo.lock也不会动。如果你是因为环境坏了要重装，建议先备份%CARGO_HOME%\config.toml和%CARGO_HOME%\registry（后者是依赖缓存，重装后能省下重新下载的时间）。

什么情况下值得重装而不是修？我的判断标准是：如果问题是“找不到编译器或链接器”且你已经排查超过一小时，重装生成工具 + rustup 的总成本通常低于继续深挖。Rust 的安装本身很轻量，重来的代价小；反倒是被改乱的 PATH 和环境变量，越修越乱，最后连自己改了什么都不记得。

另外提一个容易被忽略的点：Windows 上装完 Rust 之后，%USERPROFILE%下会多出.cargo和.rustup两个隐藏目录（以点开头，资源管理器默认不显示）。有些人做磁盘清理时看到“未知的大目录”直接删了，结果第二天发现所有 Rust 项目都编译不了。如果你有清理习惯，把这两个目录加进白名单。

双向链路共存这件事也顺带说清楚。想同时保留 MSVC 和 GNU，直接rustup toolchain install stable-x86_64-pc-windows-gnu，然后在需要的时候rustup default stable-x86_64-pc-windows-gnu切换。两条链路的依赖缓存是分开的（target目录里的子目录名带 target triple），互不干扰。我通常只在验证某个 crate 的跨平台兼容性时才会切到 GNU，日常主力还是 MSVC。

装完之后那一周，我建议刻意多用cargo check和cargo clippy，把这两个命令变成肌肉记忆。Rust 的所有权检查本来就严格，clippy 会把很多“能编译但写得不对劲”的地方标出来，比如多余的clone()、可以用if let简化的match、性能上有隐患的字符串拼接。刚开始会被警告数量吓到，但逐个看完之后，你对这门语言的理解会比读十篇教程都快。