Rust 项目依赖一多，经常会出现同一个 crate 被不同版本各带一份。先跑这个比直接翻 Cargo.lock 快：
# Rust 1.44+，在包含 Cargo.toml 的目录执行
cargo tree -d
它只列出重复版本的依赖，并把引入路径展开。想看某个包是谁带进来的，可以再缩小范围：
cargo tree -i [email protected]
-i 需要填当前解析到的精确版本；版本不确定时先用 cargo tree -d 看结果。这个检查不会改 Cargo.toml 或 Cargo.lock，适合排查构建体积和特性不一致的问题。
补充一个排查思路：重复版本不一定都能直接合并，先看是谁引入的再决定是否处理。cargo tree -i crate_name@version 可以反向展开依赖路径；如果怀疑是 feature 导致的构建差异，再加 -e features 看特性流转。处理完记得跑 cargo check，只看树不代表代码一定能兼容。
FinleyLv1#1 补充一个排查思路：重复版本不一定都能直接合并，先看是谁引入的再决定是否处理。
cargo tree -i crate_name@version可以反向展开依赖路径；如果怀疑是 feature 导致的构建差异，再加-e features看特性流转。处理完记得跑cargo check，只看树不代表代码一定能兼容。
如果项目是 workspace，我一般还会先加 -p 包名，不然整棵依赖树容易把问题淹没。只想看运行时依赖时可以试试 cargo tree -d --edges normal，把 build/dev 依赖先排除；确认重复版本确实来自生产路径后，再考虑升级或加约束，避免为了减少一份 crate 反而影响构建。
隔壁空白Lv1#2 如果项目是 workspace，我一般还会先加
-p 包名，不然整棵依赖树容易把问题淹没。只想看运行时依赖时可以试试cargo tree -d --edges normal，把 build/dev 依赖先排除；确认重复版本确实来自生产路径后，再考虑升级或加约束，避免为了减少一份 crate 反而影响构建。
再补一个判断点：看到重复版本先别直接把它当成体积问题。cargo tree -d 也会把 build/dev 依赖算进来，而它们未必进入最终产物。可以先用 cargo tree -d --edges normal -p 包名 缩小到目标包的正常依赖，再结合 cargo build --release 后的产物变化确认是否值得处理；否则单纯为了少一份 crate，可能只是增加升级风险。
如果问题只在某个平台构建时出现，可以加 --target all 看所有 target 条件下的重复依赖：
cargo tree -d --target all -p 包名
默认只看当前 target，跨平台 CI 可能会漏掉另一套依赖。这个仍是静态分析，最后还是要在目标平台跑 cargo check 或构建确认。
MukiLv1#4 如果问题只在某个平台构建时出现，可以加
--target all看所有 target 条件下的重复依赖：cargo tree -d --target all -p 包名默认只看当前 target，跨平台 CI 可能会漏掉另一套依赖。这个仍是静态分析，最后还是要在目标平台跑
cargo check或构建确认。
--target all 适合先做全局排查，不过输出可能把各平台专用依赖也混在一起。要定位 CI 的某个 runner，我会改成 cargo tree -d --target x86_64-unknown-linux-gnu -p 包名，和实际构建目标保持一致；否则看到的重复版本不一定会出现在那条流水线里。