根本原因是Cargo 1.93–1.94强化target/并发安全机制，多进程争用内存中crate级fingerprint锁导致死锁；解决方法是用--target-dir指定隔离构建目录，如./target/debug-vscode。
为什么 cargo run 会卡在 “Building …” 或报错 “target dir is locked”
根本原因是 Cargo 在 1.93–1.94 版本中强化了 target/ 目录的并发安全机制，但默认行为仍可能触发锁竞争——尤其当你同时执行 cargo run、cargo test、cargo check，或 VSCode 后台自动触发 rust-analyzer 的构建任务时。
锁不是“文件锁”，而是内存中由 Cargo 进程维护的细粒度锁（per-crate fingerprint lock），用于协调缓存命中判断。一旦多个 Cargo 实例尝试升级锁（比如一个在读 fingerprint，另一个想写），就可能陷入死锁，表现为终端无响应、VSCode 状态栏一直显示 “Building…”、甚至 cargo clean 都失败。
- 最常见诱因：rust-analyzer 自动触发
cargo check+ 你手动运行cargo run—— 两者都试图持有target/锁 - Windows 上更频繁：因为文件系统锁语义与 Unix 不同，且 PowerShell 终端继承 PATH 不稳定，容易导致多个 toolchain 实例混用
-
Cargo.lock被修改（如依赖更新）后未cargo clean，旧锁状态残留也会干扰新构建
如何绕过 target 目录锁，而不是等它释放
别等，直接切隔离路径。Cargo 支持通过 --target-dir 指定独立构建目录，这是最干净的解法——不是“绕过锁”，而是让每个命令用自己专属的 target/，彻底消除竞争。
VSCode 中最实用的是在 launch.json 里加参数，而非改全局配置：
{
"version": "0.2.0",
"configurations": [
{
"type": "lldb",
"request": "launch",
"name": "Debug",
"cargo": {
"args": ["build", "--target-dir", "./target/debug-vscode"],
"env": {}
},
"args": [],
"program": "${workspaceFolder}/target/debug-vscode/deps/${input:binName}"
}
],
"inputs": [
{
"id": "binName",
"type": "promptString",
"description": "Binary name (e.g., my_project)"
}
]
}
-
--target-dir必须是相对路径或绝对路径，不能是~或环境变量，否则 Cargo 解析失败 - 不要设为
./target/vscode—— 因为target/下已有debug/和release/，再嵌套易混淆；推荐./target/debug-vscode这类明确用途的命名 - rust-analyzer 仍会用默认
target/，所以它和调试器不会抢同一目录，但你也得接受：VSCode 的“转到定义”和调试看到的符号来自不同构建产物（通常不影响开发）
什么时候该启用 Cargo 工作区分片（workspace per-crate）
单 crate 项目没必要分片；只有当你的项目已拆成 Cargo 工作区（workspace.members 列出多个 crate），且频繁出现跨 crate 构建冲突时，才值得考虑分片策略。
分片不是指物理拆硬盘，而是让每个 crate 使用独立 target/ 目录。方法很简单，在每个 crate 的 Cargo.toml 里加：
[profile.dev] # 只影响本 crate 的 debug 构建 target-dir = "target-dev"
- 这个设置只对
cargo build --profile dev（即默认cargo build）生效；cargo test仍走全局target/，除非你也给 test 加--target-dir - 工作区共享
Cargo.lock，但分片后各 crate 的target/完全隔离 —— 编译速度略降（无法复用中间产物），但锁冲突归零 - CI 场景慎用：某些 CI runner（如 GitHub Actions）默认缓存
target/，分片后缓存失效，构建时间反而上升
rust-analyzer 的锁行为与你能控制的边界
rust-analyzer 本身不持有文件锁，但它调用 cargo metadata 和 cargo check 时，会触发 Cargo 的锁逻辑。你无法禁用它的构建行为，但可以限制其作用域。
关键控制点在 rust-analyzer.serverPath 和 rust-analyzer.cargo.loadOutDirsFromCheck：
- 确保
rust-analyzer.serverPath指向和cargo同一 toolchain 的rust-analyzer（比如都用 stable），否则两个进程可能用不同版本 Cargo，锁协议不兼容 - 关掉
"rust-analyzer.cargo.loadOutDirsFromCheck": false—— 默认为 true，意味着它会主动执行cargo check并读取输出目录；设为 false 后，它只靠cargo metadata推导结构，不触发构建，锁冲突概率大幅下降 - 如果项目有大量
#[cfg(test)]代码，rust-analyzer 默认会包含它们分析；加"rust-analyzer.cargo.runBuildScripts": false可跳过 build script 执行，进一步减少锁争用
真正难处理的，是那些没显式声明依赖、却在构建时动态生成代码的 crate —— 它们会让 rust-analyzer 和 cargo 的锁节奏错位，这时候分片或隔离 --target-dir 是唯一靠谱的路。
