VSCode 不配置 Cargo，仅调用 PATH 中的 cargo；验证 cargo --version 和 rustc --version 是前提，失败则需修复环境变量；必须安装 rust-analyzer 插件并禁用旧插件；启用 rust-analyzer.checkOnSave.enable 实现保存时 cargo check；调试前须手动 cargo build 且确保 debug=2。
VSCode 本身不“配置”Cargo，它只调用系统中已安装且 PATH 可见的 cargo；所有“配不成功”的现象，90% 是因为 cargo --version 在 VSCode 内置终端里根本跑不通。
验证 cargo 和 rustc 是否真可用
这是所有后续操作的前提。别跳过这步，也别信“我装过了”。在 VSCode 里按 Ctrl+` 打开内置终端，直接运行：
-
cargo --version必须输出类似cargo 1.79.0 -
rustc --version必须输出类似rustc 1.79.0
如果任一命令报 command not found，说明 rustup 安装的 bin 目录没进 VSCode 的环境变量上下文：
- Linux/macOS：别用桌面图标启动 VSCode，关掉后在终端执行
code .（确保 shell 已加载$HOME/.cargo/env） - Windows：检查系统环境变量是否含
%USERPROFILE%\.cargo\bin；若 rustup 安装时没勾选 “Add to PATH”，得手动加
rust-analyzer 是唯一要装的插件，其他 Rust 插件必须禁用
VSCode 商店搜 “Rust”，你会看到两个高排名插件：
-
rust-lang.rust（红黑齿轮图标，已废弃）→ 必须卸载或禁用 -
matklad.rust-analyzer（蓝色原子图标，当前事实标准）→ 必须安装
二者共存会导致 CPU 持续 100%、跳转失效、补全卡死，甚至静默禁用 rust-analyzer。装完后，打开含 Cargo.toml 的目录，状态栏右下角应显示 Rust (rust-analyzer)；若显示 Rust (RLS) 或空白，说明没生效——关掉所有窗口，用 code . 从项目根目录重开。
保存时自动 cargo check，不是 cargo build
用 cargo build 做保存检查是典型误配：它会生成二进制、链接依赖、耗时长，还容易因 target/ 权限或缓存卡住。而 cargo check 只做语义分析，快、准、专为编辑反馈设计。
- 启用方式：设置里搜
rust-analyzer.checkOnSave.enable，勾上即可 - 想检查 tests/examples：在
settings.json中加："rust-analyzer.checkOnSave.extraArgs": ["--all-targets"]
- 想启用所有 features：加
"rust-analyzer.cargo.args": ["--all-features"]
- 别手动写
tasks.json绑定保存事件——rust-analyzer自带的checkOnSave更稳，且和 Problems 面板原生对齐；自己配 task 容易漏"problemMatcher": "$rust"，导致错误不显示
调试前必须先 cargo build，且确认 debug = 2
VSCode 默认调试配置用 cargo run，每次都会重新编译。但源码改了没保存、或 cargo 缓存未更新时，调试器实际加载的是旧二进制——断点自然不命中。
- 正确做法：调试前先手动运行
cargo build（非--release），确保target/debug/下有最新可执行文件 - 检查
Cargo.toml是否含[profile.dev.debug = 0]—— 这行会关掉调试信息，删掉或设为2（默认值） - 修改
.vscode/launch.json，把"args"改成["build"]，并确认"stopOnEntry": false；这样调试器直接加载已构建好的二进制，稳定得多
真正容易被忽略的是 workspace 根目录的 Cargo.toml：rust-analyzer 不会向上递归找它，也不会识别子目录里的 Cargo.toml；如果你在 crates/my-lib/ 下打开 VSCode，但根目录没有 [workspace] 声明，跨 crate 的跳转和补全就全废了。
