解读

在国内 Rust 面试中，面试官问“如何共享依赖版本”并不是想听“把版本号写死”这种初级回答，而是考察候选人是否真正用 Cargo 做过多 crate 协同开发、是否理解语义化版本与锁文件的分工、是否能在团队协作与持续集成场景下保证“所有人、所有环境编译结果一致”。
一句话：让同一工作区（workspace） 里的所有成员 crate 共用一份“依赖解析结果”，并保证本地、CI、生产三端无偏差。

知识点

1. Cargo.workspace 机制
   顶层 Cargo.toml 声明 [workspace]，统一解析依赖并生成唯一 Cargo.lock；成员 crate 通过 workspace = true 继承版本，避免菱形依赖冲突。
2. Cargo.lock 的角色
   二进制 crate 默认把 lock 文件提交到 git，保证 CI 与本地 bit-for-bit 一致；库 crate 不提交 lock，但工作区根目录的 lock 对所有成员生效。
3. 语义化版本与兼容性
   Cargo 使用最大版本解析策略（Max Version Resolution），只要符合 ^x.y.z 约束就允许升级补丁或次版本；共享版本≠强制降级，而是让解析器在同一工作区内只选一个满足所有约束的版本。
4. 国内镜像与网络一致性
   在 .cargo/config.toml 中统一配置科大、清华或字节源，避免“同事 A 用 crates-io，CI 用镜像”导致解析哈希不一致。
5. CI 加固手段
   使用 cargo generate-lockfile --offline 或 cargo fetch --locked 提前拉完依赖，防止编译时刻网络抖动；配合 CARGO_NET_RETRY=10 提高成功率。
6. 版本覆盖与补丁
   若必须强制统一某个 transitive 依赖，可在工作区根写 [patch.crates-io]，一次性覆盖所有成员的解析结果，无需逐 crate 改 toml。

答案

1. 建立 Cargo workspace：在仓库根目录创建 Cargo.toml，声明

   [workspace]
   members = ["crates/*"]
   resolver = "2"
   

   这样整个仓库只产生一份 Cargo.lock，所有成员 crate 自动共享解析结果。
2. 把** Cargo.lock 加入 git**：
   对于二进制项目（含工作区根）必须提交，确保同事、CI、线上编译机拿到同一组依赖哈希；库项目如被外部引用，可不提交，但在工作区内仍受根 lock 约束。
3. 统一国内镜像：
   在 .cargo/config.toml 写入

   [source.crates-io]
   replace-with = 'ustc'
   [source.ustc]
   registry = "https://mirrors.ustc.edu.cn/crates.io-index"
   

   保证首次解析与后续 fetch 的索引哈希一致，避免“本地能编、CI 失败”。
4. 使用 workspace 继承：
   在根 Cargo.toml 声明

   [workspace.dependencies]
   tokio = { version = "1.35", features = ["full"] }
   serde = { version = "1.0", default-features = false }
   

   成员 crate 里写

   [dependencies]
   tokio = { workspace = true }
   serde = { workspace = true }
   

   后续只需在根文件改一次版本号，即可原子级升级整个工作区，杜绝漏改、版本漂移。
5. 若出现 transitive 依赖冲突，用 [patch] 在工作区根一次性强制收敛版本，无需逐 crate 排查。
6. CI 流程中先执行

   cargo fetch --locked
   

   把依赖预先拉到缓存，后续 cargo build --release 不再访问网络，既提速又保证离线可重复。

拓展思考

1. 大单体 vs 多仓库：
   当仓库规模超过 300 个 crate，工作区解析耗时明显上升，可考虑拆分独立工作区并用 cargo vendor 把依赖源码打进内网 Git，实现“源码级锁定”，彻底隔绝外部网络变动。
2. ** semver 自动升级策略**：
   在根 Cargo.toml 把版本写成 "1" 而非 "1.35"，让 Cargo 在兼容范围内自动选最新补丁，配合每周一次的 dependabot 扫描，在安全与稳定之间取得平衡；但发布前必须用 cargo update -p <crate> --precise <y> 回退到指定版本，并重新跑一遍 miri + loom 测试，确保内存与并发模型未被破坏。
3. 与 C/C++ 混合编译：
   若工作区里部分 crate 通过 cc crate 编译本地 C 库，需在 .cargo/config.toml 统一 TARGET_CC、CFLAGS，避免“同事 A 用 gcc-9，CI 用 gcc-11”导致符号 ABI 不一致；可把工具链版本写入 rust-toolchain.toml 并在 docker 镜像里固化，实现 Rust 依赖与系统依赖的双重锁定。