同一个 crate 出现多个版本时，先看重复项：
cargo tree -d
它会列出重复版本和依赖链，不会修改 Cargo.toml 或 Cargo.lock。想反查某个版本是被谁带进来的，可以接着跑：
cargo tree -i [email protected]
把包名和版本换成前一条输出里的实际值。命令在包含 Cargo.toml 的项目目录执行，环境是 Rust 1.65+ / Cargo。重复版本不一定就是问题，但通常值得检查一下依赖约束有没有错开。
再补一个判断思路：重复版本先别急着合并，先看它们是不是不同 major，还是两个依赖的 semver 约束没有交集。workspace 项目可以用：
cargo tree --workspace -d
cargo tree --workspace -i [email protected]
前一个看整个 workspace，后一个追某个版本的引入路径。能调整时，优先检查直接依赖的版本范围；Cargo.lock 里的版本也别直接手改。
Zoe_JayLv1#1 再补一个判断思路：重复版本先别急着合并，先看它们是不是不同 major，还是两个依赖的 semver 约束没有交集。workspace 项目可以用：
cargo tree --workspace -d cargo tree --workspace -i [email protected]前一个看整个 workspace，后一个追某个版本的引入路径。能调整时，优先检查直接依赖的版本范围；
Cargo.lock里的版本也别直接手改。
如果还想排查 feature 是怎么被带进来的，可以再看 feature 传播：
cargo tree -e features -i [email protected]
这样能看到反向依赖和 feature 来源。-d 只说明版本重复，不代表一定有问题；有时只是 feature 组合不同，先看这棵树再决定要不要调整直接依赖，会稳一点。
别熬夜啦Lv1#2 如果还想排查 feature 是怎么被带进来的，可以再看 feature 传播：
cargo tree -e features -i [email protected]这样能看到反向依赖和 feature 来源。
-d只说明版本重复，不代表一定有问题；有时只是 feature 组合不同，先看这棵树再决定要不要调整直接依赖，会稳一点。
如果只是想判断重复版本会不会进发布构建，可以先收窄依赖边：
cargo tree -d --edges normal
这样能先排掉只在 dev/build 依赖里的重复项。要是只在测试环境重复，通常不用为了“树看起来干净”硬合并；真正影响运行时的，再结合 workspace 和 feature 传播继续追。