在工作区Cargo.toml中定义所有依赖是否存在弊端？

存在的弊端 #

把所有依赖（哪怕仅被单个crate使用）都放在工作根目录的Cargo.toml里，主要有这些问题：

• 依赖归属模糊：单个crate自己的Cargo.toml失去了明确依赖列表的作用，别人看代码时没法快速知道这个crate到底依赖哪些库，排查依赖冲突、清理无用依赖都会变得棘手。比如要升级某个仅用于测试工具的依赖，得先逐一确认其他业务crate没用到它，才能放心操作。
• 误引用风险提升：工作区根的依赖对所有成员crate可见，哪怕某个crate原本不需要某依赖，也能直接引用，很容易导致依赖范围意外扩大，最终编译出的产物包含多余代码，还可能引入不必要的兼容性问题。
• 版本升级灵活性受限：工作区的依赖是全局统一版本的，如果某个crate需要单独升级某个依赖的版本，就必须修改工作区根配置，这会强制所有用到该依赖的crate同步升级——哪怕其他crate还没做好兼容准备，很容易引发连锁编译错误。
• 本地资源浪费：当你只需要构建某个特定crate时，工作区根的所有依赖都会被拉取并编译，哪怕大部分和当前crate无关。比如工作区里有一个API服务crate和一个数据处理crate，后者依赖了一堆机器学习库，当你只想构建API服务时，这些机器学习库也会被编译，白白占用磁盘空间和内存。

关于编译时间的判断 #

你的想法不完全正确：

• 首次拉取依赖时，不管依赖放在工作区根还是单个crate里，确实都需要下载所有依赖包，这一步的时间差异不大。
• 但增量编译阶段差异明显：如果依赖放在单个crate里，修改某个不相关的crate时，只有该crate及其直接依赖会重新编译；但如果所有依赖都在工作区根，一旦某个依赖的版本变更（哪怕只是配置里的版本号修改），所有可能用到该依赖的crate都会触发重新编译，哪怕实际没用到。
• 另外，使用cargo build --package <crate-name>单独构建某个crate时，Cargo本可以只编译该crate的必要依赖，但如果依赖都在工作区根，Cargo可能会提前编译所有工作区依赖（尤其是启用了members配置时），导致额外的编译开销。

内容的提问来源于stack exchange，提问作者Mads Hougesen