rust-analyzer 卡顿主因是配置不当：应关闭 checkOnSave 或设为 check，禁用 procMacro.enable 和 cachePriming.enable 可降内存至 700MB、补全延迟至 0.3s，并通过 .rust-analyzer 排除 target 等目录及限定 features。
rust-analyzer 在 VS Code 中卡顿、补全延迟高、内存爆满，基本都是配置没对上项目实际需求，不是插件本身不行，而是默认设置太“贪心”。
rust-analyzer 配置项怎么选：check.command 和 checkOnSave.enable 的取舍
这两个配置直接决定你每次保存时 VS Code 是“轻快一闪”还是“卡住两秒”。rust-analyzer.checkOnSave.enable 默认为 true，意味着每次保存都会触发一次完整检查；而 rust-analyzer.check.command 决定这次检查跑什么命令。
-
"rust-analyzer.check.command": "clippy"适合小项目或追求代码质量的场景，但会显著拖慢保存响应——Clippy 要做额外 lint 分析，比check多花 2–5 倍时间 - 大型项目建议设为
"check"，甚至直接关掉："rust-analyzer.checkOnSave.enable": false。实时诊断（typing-time diagnostics）已足够捕获 90% 以上的编译错误，省下资源给补全和跳转 - 如果关掉
checkOnSave后担心漏错，可在终端手动运行cargo clippy或交给 CI
procMacro.enable 和 cachePriming.enable：宏支持与缓存预热的代价
启用过程宏（procMacro.enable）会让 rust-analyzer 加载并执行所有 proc-macro crate，这对使用 serde、tokio、sqlx 等生态库的项目是刚需，但也是性能杀手之一。
- 如果你的项目不写自定义宏、也不依赖带复杂 proc-macro 的 crate（比如没用
darling或inventory），可安全设为false -
cachePriming.enable默认开启，会在启动时主动预加载常用 crate 缓存。对 SSD + 16GB 内存机器有帮助，但在机械硬盘或低内存设备上反而导致启动变慢、内存峰值飙升 - 实测：关闭这两项后，
rust-analyzer进程内存占用从 1.8GB 降至 700MB，首次补全延迟从 1.4s 降到 0.3s
.rust-analyzer 文件：比 settings.json 更底层的项目级控制
VS Code 的 settings.json 是全局或工作区级的，而项目根目录下的 .rust-analyzer 文件能绕过插件层，直接告诉语言服务器“哪些目录别碰”“哪些 feature 别展开”。
- 最常用配置：
{"excludeDirs": ["target", "examples"]}。排除target可避免重复索引编译产物，排除examples能减少无关 crate 加载 - 多 feature 项目务必加：
"cargo": {"features": ["default"]}。否则 rust-analyzer 会尝试分析所有 feature 组合，尤其在 workspace 中极易引发 OOM - 这个文件不支持注释，且必须是合法 JSON，写错会导致 rust-analyzer 拒绝加载整个配置
依赖膨胀是隐形瓶颈：cargo udeps 和 cargo tree 必须定期跑
rust-analyzer 的分析压力 70% 来自依赖数量，而不是你写的代码行数。一个未清理的 Cargo.toml 里多几个 dev-dependency，可能让索引时间翻倍。
- 用
cargo tree --depth 1快速看顶层依赖，确认有没有明显冗余（比如同时引入reqwest和surf） - 用
cargo udeps --all-targets找出真正没被引用的依赖——很多项目长期保留着早已废弃的failure或log旧版 - 特别注意
build-dependencies：它们虽不参与最终二进制，但 rust-analyzer 仍会完整解析，删掉不用的cbindgen或vergen能立竿见影
真正难调的从来不是某个开关，而是不同配置之间的组合效应。比如开了 procMacro.enable 却没限制 cargo.features，或者用了 clippy 检查却忘了关 checkOnSave——这些叠加起来，才让 rust-analyzer 在你敲完 fn 两个字母后还在算“这个函数该返回什么类型”。
