rust-analyzer补全失效主因是vscode未正确识别项目根或cargo工作区结构，需禁用rls、打开含cargo.toml的根目录、启用procmacro和loadoutdirsfromcheck等关键配置。

rust-analyzer 能提供比 RLS 快得多的补全体验，但默认安装后常不生效——核心问题在于 VSCode 没正确识别项目根或 cargo 工作区结构，不是插件本身慢，而是它根本没加载对的 target。

确认 rust-analyzer 插件已启用且为首选语言服务器

VSCode 默认可能同时启用 RLS 或旧版 Rust (rls) 扩展，它们会和 rust-analyzer 冲突。必须手动禁用：

• 在扩展面板中搜索 Rust (rls)、RLS，全部禁用（不是卸载）
• 确保已安装官方 rust-analyzer 扩展（作者是 matklad）
• 打开任意 .rs 文件，按 Ctrl+Shift+P 输入 Developer: Toggle Developer Tools，在 Console 中搜 rust-analyzer，看到类似 Starting rust-analyzer server 即表示正在运行

确保工作区根目录包含 Cargo.toml 或 rust-project.json

rust-analyzer 不依赖 cargo 命令实时扫描，而是靠静态项目定义文件定位 crate 和依赖。若你打开的是子目录（比如 ./crates/my-lib），它大概率无法推导出完整依赖图：

VSCode

避免常见的 VSCode 错误——设置冲突、调试器配置和扩展冲突。

下载

• 务必用 VSCode 打开整个 workspace 根目录（即含顶层 Cargo.toml 或 rust-project.json 的文件夹）
• 若项目是多 crate workspace，确保顶层 Cargo.toml 有 [workspace] 块，且所有成员路径正确
• 没有 Cargo.toml？可手动生成最小 rust-project.json：

  {
    "sysroot": "/path/to/rust/sysroot",
    "crates": [{ "root_module": "src/lib.rs", "deps": [], "cfg": ["test"] }]
  }

  （但强烈建议优先用 Cargo.toml）

检查 rust-analyzer 配置是否禁用了关键功能

VSCode 设置里几个开关直接影响补全速度和覆盖率：

• rust-analyzer.cargo.loadOutDirsFromCheck：设为 true，否则 #[cfg(test)] 下的代码可能不被索引
• rust-analyzer.procMacro.enable：设为 true，否则 derive、tokio::main 等宏展开后无法跳转/补全
• rust-analyzer.checkOnSave.command：推荐设为 check（而非 clippy），避免保存时卡住补全响应
• 不要开启 rust-analyzer.cargo.unsetTestEnvironment，否则 #[cfg(test)] 补全失效

补全仍卡顿？重点排查这三处

真实场景下最常拖慢补全的不是网络或硬件，而是本地配置误伤：

• 项目用了 build.rs 且执行耗时？rust-analyzer 默认不运行它，但若你手动启用了 rust-analyzer.cargo.runBuildScripts，就会阻塞索引
• target/ 目录被 VSCode 全局 files.exclude 隐藏？rust-analyzer 需要读取 target/debug/.rustc_info.json，排除它会导致反复重索引
• 用了非标准 toolchain（如 rustup toolchain link my-toolchain /path）？需在设置中显式指定：rust-analyzer.rustcSource: "discover" 或 "fromSysroot"

补全延迟往往藏在“它以为自己在工作，其实卡在某个 cfg 分支或宏展开层级”。观察状态栏右下角的 rust-analyzer 图标：如果长时间显示 “Indexing…” 或图标变灰，八成是项目结构没对上，而不是需要升级硬件。