VS Code 原生不支持 Rust 实时协作结对开发，因 rust-analyzer 是单机运行、不共享 AST/类型上下文/宏展开状态；Live Share 不转发 LSP 请求，导致调试、跳转、补全、变量查看均无法真正协同。
VS Code 原生不支持 Rust 项目的实时协作结对开发——rust-analyzer 的语言服务是单机本地运行的，不共享 AST、类型上下文或宏展开状态；多人同时编辑同一文件时，补全、跳转、错误提示会各自独立计算，且极易因缓存不一致导致“对方看到的类型和你不一样”。
为什么 Live Share + rust-analyzer 无法真正协同调试和跳转
VS Code 的 Live Share 插件能共享终端、调试会话和编辑器光标，但它不转发语言服务器（LSP）请求。也就是说：
- 协作者 A 在自己机器上启动
rust-analyzer，只分析自己本地target/和Cargo.lock缓存，A 看到的类型推导结果不会同步给 B - B 编辑同一行代码时，
rust-analyzer可能因本地target/过期或未构建而报 “unresolved type”，但 A 看不到这个错误 - 断点设置在 B 的调试器里有效，但 A 无法查看变量值——因为
CodeLLDB的变量求值依赖本地调试进程和符号表，不跨网络共享内存状态 - 如果项目启用了 proc-macro（如
serde、tokio），而 B 没装对应 crate 的源码（rustup component add rust-src），B 的补全将大面积失效，A 却完全无感知
可行的轻量级结对方案：共享终端 + 同步 Cargo 构建状态
绕过 LSP 协同瓶颈，聚焦可落地的协作点：
- 用
Live Share共享一个终端（推荐zsh或pwsh），双方都执行cargo build --message-format=json，再用jq或cat target/debug/deps/my_project-*.d快速确认构建产物是否一致 - 禁用各自 VS Code 的自动保存（
"files.autoSave": "off"），改用手动Ctrl+S+git add -p分块暂存，避免未编译就推送脏代码 - 在
settings.json中统一配置"rust-analyzer.check.command": "clippy"，确保两人 lint 规则一致；若发现 clippy 提示不一致，立刻检查Cargo.toml中[dev-dependencies]是否漏加clippy - 共享一个
.cargo/config.toml，强制指定build.target-dir = "../shared_target"，让两人构建输出写入同一目录，减少因target/冗余引发的误判
rust-analyzer 多人协作时最易被忽略的缓存陷阱
rust-analyzer 会在 $CARGO_HOME/registry/src/ 和 $RUSTUP_HOME/toolchains/ 下缓存 crate 源码与分析结果，但这些路径默认不随项目 Git 管理，也不被 Live Share 同步：
- 协作者 A 更新了
tokio = "1.37"，cargo update后rust-analyzer自动下载新版本源码并重分析；B 若没手动触发cargo update，仍用旧版tokio源码分析，导致tokio::spawn补全缺失或类型错误 - 解决方法：把
cargo update && cargo check封装成一键脚本，协作前双方先运行；或用watchexec -w Cargo.lock -e toml,cargo -- cargo check自动响应依赖变更 - 临时救急：当发现补全异常时，不要重启 VS Code，而是执行命令面板中的
Rust Analyzer: Reload Workspace（快捷键Ctrl+Shift+P→ 输入该命令），它比重启快 3–5 秒，且不丢失断点状态
真正的 Rust 结对开发难点不在“能不能看到对方光标”，而在“两个人是否在同一个抽象语法树上思考”。工具能同步编辑行为，但无法同步理解——这需要每次 cargo check 通过后，花 10 秒对齐一句 println!("{:#?}", expr) 的实际输出，而不是依赖 IDE 显示的 inlay hint。
