Rust工作区依赖与核心库重导出的功能差异有哪些？

问题背景 #

我有一个中等规模的Rust工作区，拆分为多个专注模块，所有模块都扩展包含核心模型和trait的内部核心库，目录结构如下：

app
lib/
  + core/
  + macros/
  + models/
modules/
  + [etc.]

依赖层级为 macros->models->core->[modules]->app。目前我已配置核心库重导出应用核心功能所需的外部库结构（如 chrono::{DateTime, Utc} 和 async-trait），同时在Cargo.toml中定义了 log、test-case、tokio 等工作区依赖，以及内部核心库引用。

想请教：除了每个项目需配置 dependencyname.workspace = true 外，在工作区多项目共享依赖时，重导出依赖与定义工作区依赖是否存在功能差异？我目前所知的唯一实际差异是重导出属于导出它们的模块的“子项”。

核心差异解析 #

除了你提到的“重导出属于导出模块的子项”这一点，两者还有以下关键功能差异：

1. 版本一致性保障机制不同 #

• 工作区依赖：通过工作根目录的Cargo.toml统一声明版本，子 crate 用workspace = true引用，强制所有子项目使用完全相同的依赖版本，彻底避免版本不一致引发的编译错误或行为偏差。
• 重导出：子 crate 本质是自行引入依赖（即便版本和工作区一致），仅通过内部 crate 暴露接口。若某个子 crate 私自指定不同版本，Cargo 会按依赖规则解析，可能出现同一依赖多版本共存的情况，破坏一致性。

2. API使用的约束范围不同 #

• 工作区依赖：子 crate 声明后可直接使用该依赖的全部公开API，无需通过内部 crate 中转。
• 重导出：子 crate 只能通过导出依赖的内部 crate（如你的core）使用，且仅能用到被重导出的那部分API。若需使用该依赖的其他未导出功能，要么修改内部 crate 新增重导出，要么子 crate 自行添加依赖（再次引入版本一致性问题）。

3. 构建效率与缓存逻辑不同 #

• 工作区依赖：Cargo 在工作区层面统一缓存编译后的依赖产物，所有子项目共享同一编译结果，构建速度更快。
• 重导出：若子 crate 自行添加依赖（哪怕版本匹配），部分场景下会触发重复编译；即便完全通过重导出使用，依赖链更长也会增加Cargo的解析成本。

4. 项目架构耦合度不同 #

• 工作区依赖：子 crate 直接依赖工作区声明的外部库，与内部核心 crate 的耦合度更低，适合无需和核心逻辑强绑定的功能模块。
• 重导出：子 crate 必须依赖内部核心 crate 才能使用外部库，强化了核心 crate 作为架构枢纽的角色，适合需要统一规范外部库使用方式的场景（比如强制所有时间处理都用core导出的chrono类型）。

5. 依赖更新的维护成本不同 #

• 工作区依赖：更新版本仅需修改根目录的Cargo.toml，所有子项目自动同步，无需逐个调整。
• 重导出：若依赖版本由核心 crate 控制，更新时只需修改核心 crate 的依赖版本，所有通过重导出使用的子项目会自动同步；但如果有子项目自行添加了该依赖，就需要单独更新这些子项目的版本，维护成本更高。

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