Cargo tree 怎么找出同时编译多个版本的依赖

当 Rust 项目的构建时间变长、依赖体积变大，或者锁文件里出现同名 crate 的多个版本时，可以先用 cargo tree --duplicates 把范围缩到“确实会以多个版本出现”的依赖。这个命令适合做定位和收敛线索整理：它能告诉你哪些 crate 重复、哪些上游路径带入了旧版本，但不会替你直接改 Cargo.toml。

官方地址：https://doc.rust-lang.org/cargo/commands/cargo-tree.html

先确认重复依赖结果长什么样

Cargo Book 对 --duplicates 的定义很直接：只显示以多个版本出现的依赖，并隐含 --invert。因此它不是普通的完整依赖树，而是把注意力放到“同一个 crate 为什么被不同路径带进来”。同一个包的版本可能因为 SemVer 不兼容、不同上游的约束，或工作区成员的依赖范围不同而同时存在。

这个结果不等同于“所有重复依赖都应该立即合并”。有些旧版本受上游约束，强行替换可能破坏兼容性；更稳妥的第一步是确认来源、版本和可升级的上游 crate。

从项目入口执行 Cargo tree 查询

进入包含 Cargo.toml 的项目目录后，先执行最小查询。命令输出会保留依赖树结构，便于继续阅读哪个上游节点把某个版本带进来。

# 在 Cargo.toml 所在项目中，只列出多版本依赖及其反向路径
cargo tree --duplicates

如果项目是虚拟工作区，或者你希望把所有工作区成员放在一起查看，可以显式加上 --workspace：

# 将工作区成员的依赖一起纳入重复版本查询
cargo tree --workspace --duplicates

这里的“操作成功”不是命令一定要找到重复项，而是终端能够返回一份依赖树结果。若没有重复版本，输出为空也可能是当前范围内没有匹配项；仍要结合后面的目标平台和依赖类型范围复查。

按工作区、包和依赖类型收窄范围

第一次查询通常会把多个成员和多种依赖类型混在一起。为了让结果可读，可以把范围缩小到一个成员包。-p 的值应换成工作区中的实际包名：

# 只查看指定工作区成员的重复依赖，包名替换为项目中的真实名称
cargo tree --workspace -p app-core --duplicates

默认依赖边包含普通依赖、构建依赖和开发依赖。如果问题只在构建脚本或测试阶段出现，可以用 -e 指定边类型：

# 只看构建依赖，便于排查 build.rs 或构建工具带入的重复 crate
cargo tree --workspace -p app-core --duplicates -e build

# 只看开发依赖，便于区分测试工具是否制造了另一条版本路径
cargo tree --workspace -p app-core --duplicates -e dev

目标平台也会影响解析结果。官方文档说明，默认目标是当前主机；如果项目为多个平台分别解析依赖，应把目标作为独立查询维度：

# 查看所有目标平台都可能出现的重复依赖，结果可能比主机范围更宽
cargo tree --workspace --duplicates --target all

沿反向依赖路径寻找收敛线索

在重复结果中，先找同名 crate 的两个版本，再看它们上方的依赖节点。由于 --duplicates 隐含反向展示，输出重点是“哪些包依赖这个重复 crate”，而不是重新展开一棵完整正向树。把旧版本的上游路径抄到记录里，就能得到下一步要检查的升级候选。

# 只围绕某个重复 crate 查看反向依赖；crate 名替换为输出中的真实名称
cargo tree --workspace --invert serde

如果同一个 crate 出现 v1.x 和 v2.x，不要只看版本号大小就判断谁应该被删除。先区分三件事：哪个直接依赖声明了旧版本、哪个间接依赖仍然锁定旧版本、升级上游后是否可能改变公开 API。Cargo tree 的作用是给出依赖关系证据，升级动作仍要回到依赖声明和锁文件变更中决定。

核对结果并留下可复用记录

可以把每次查询的范围和发现写成一条简短记录，后续升级依赖后再用同一组命令复查。记录至少包括工作区成员、目标平台、依赖类型、重复 crate 名称与版本，以及带入旧版本的上游路径。

结果核对完成后，再回到 Cargo.toml、上游 crate 的发布说明和团队升级策略中决定是否升级。本文的边界是找出重复版本和收敛方向，不直接给出强制替换或锁文件手工修改方案。

几个容易误判的情况

为什么普通的 cargo tree 看不到重复版本？

普通输出会对已经展示过的依赖做去重标记，重复位置可能显示为 (*)。--duplicates 会把重点集中到多版本依赖，更适合做专项排查。

没有输出是不是代表整个项目绝对没有重复依赖？

不一定。先确认查询的是正确工作区成员、依赖类型和目标平台；默认查询使用当前主机目标，某些平台专属依赖不会出现在同一范围里。

发现旧版本后能不能马上强制替换？

不建议把强制替换作为第一步。先找到带入旧版本的上游 crate，查看它是否已有兼容升级，再评估 API、功能特性和锁文件变化。