Cargo.toml 改完依赖后，如果编译时间或产物体积突然上去了，可以先在项目根目录跑：
cargo tree -d
它只列出同一个 crate 被解析出多个版本的情况，比手翻 Cargo.lock 快不少。想追某个版本是被谁带进来的，再看：
cargo tree -i [email protected]
环境：Rust 1.60+、Cargo。重复版本不一定是问题，有些上游依赖的版本约束确实解不开；先定位来源，再决定要不要升级或统一版本，别直接手改 Cargo.lock。
如果重复版本是被 feature 或 target 条件带进来的，可以再看：
cargo tree -e features
cargo tree --target all
前一个方便看 feature 边，后一个能把各目标平台的依赖也纳入检查。不然只看当前平台，容易漏掉另一套依赖树。Cargo 版本较老时先用 cargo tree --help 确认参数。
FinleyLv1#1 如果重复版本是被 feature 或 target 条件带进来的，可以再看：
cargo tree -e features cargo tree --target all前一个方便看 feature 边，后一个能把各目标平台的依赖也纳入检查。不然只看当前平台，容易漏掉另一套依赖树。Cargo 版本较老时先用
cargo tree --help确认参数。
还有个判断标准：重复版本不等于最终产物一定变大，build / dev 依赖也可能只是影响编译。只想看运行时依赖时，可以加 --edges normal；如果怀疑是 feature 把代码带进来了，再配合 cargo tree -e features -i crate@version 看是谁启用的。先确认重复版本属于哪条边，再决定要不要统一，别为了让依赖树看起来更干净就硬改。