Cargo 工具链没被识别？先确认 cargo 在终端里能直接运行
VSCode 找不到 cargo，不是插件问题，而是环境变量没进 VSCode 的启动上下文。Mac/Linux 下用终端启动 VSCode（code .）才能继承 shell 的 PATH；Windows 用户如果用开始菜单点开 VSCode，默认走的是系统 PATH，得确认 cargo 是否在系统级 PATH 里（比如通过 rustup 安装后没勾选“add to PATH”）。
常见错误现象：Rust Analyzer 报 “cargo not found”，或点击“Run”按钮无反应。
- 打开终端，执行
cargo --version，必须成功返回版本号 - 若失败，重装 Rust：运行
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh（Linux/macOS）或去rustup.rs下载 Windows 安装器 - 重启 VSCode（不是 reload window，是彻底关掉再打开）
Rust Analyzer 插件报 “project is not loaded” 或无法跳转定义
这不是插件坏了，而是它没找到 Cargo.toml，或者项目结构不标准。Rust Analyzer 默认只扫描工作区根目录下的 Cargo.toml，不会递归搜子目录。
使用场景：你在 ~/projects/my-crate/ 里打开 VSCode，但实际想编辑的是 ~/projects/my-crate/crates/utils 这个子 crate。
- 确保 VSCode 是在包含
Cargo.toml的目录下打开的（code ./crates/utils，而不是code ./） - 多 crate 工作区建议用
rust-project.json显式声明，内容为：{"sysroot": "discover","crates": [{"root_module": "./crates/utils/Cargo.toml","deps": [],"cfg": []}]} - 禁用其他 Rust 插件（尤其是老旧的 “Rust” 扩展），它们会和 Rust Analyzer 冲突
断点不命中？检查调试器是否用了 cargo run 而不是 cargo build
VSCode 默认调试配置生成的是 cargo run，它每次都会重新编译——看似方便，实则干扰断点稳定性：源码改了但没保存，或编译缓存导致调试器加载了旧二进制。
性能影响：cargo run 比 cargo build && ./target/debug/my-bin 多一次构建判断，对大项目明显卡顿。
- 手动修改
.vscode/launch.json，把"args"改成["build"]，并设"stopOnEntry": false - 确保
"cargo"配置项里"args"不含--release（debug info 会被 strip） - 检查
Cargo.toml中是否有[profile.dev.debug = 0]，这会关掉调试信息
rust-analyzer 和 lldb 调试器之间谁管什么
很多人以为 Rust Analyzer 能调试，其实它只负责语义分析（跳转、补全、诊断）；真打断点靠的是 VSCode 底层调用 lldb（macOS）或 gdb（Linux）或 cppvsdbg（Windows），而它们依赖可执行文件里的 DWARF/PE debug info。
容易踩的坑：装了 rust-analyzer 就以为万事大吉，结果断点灰了——其实是没装原生调试器，或没配好 lldb-vscode。
- macOS：运行
xcode-select --install确保lldb可用；验证：终端执行lldb --version - Linux：安装
gdb和rust-gdb（sudo apt install gdb+rustup component add rust-gdb） - Windows：推荐用
CodeLLDB插件（不是官方 C++ 插件），它自带lldb，且支持rustc生成的 PDB
复杂点在于：Cargo 构建时默认开启 incremental 编译，偶尔会导致 debug info 错位；遇到断点偏移，删掉 target/ 重来最稳。
