mvn dependency:tree是诊断Maven依赖混乱的核心命令，可生成完整依赖树、过滤特定依赖、识别版本冲突、导出文件分析及检测循环依赖。
当你在IDE里反复刷新Maven项目却始终报错“ClassNotFoundException”或“NoSuchMethodError”，大概率是依赖关系乱了——【mvn dependency:tree】就是专治这种混乱的命令行显微镜，它不靠猜测，直接把每个jar从哪来、谁带进来的、为什么被忽略全摊开给你看。
快速生成完整依赖树
在项目根目录（含pom.xml的文件夹）打开终端，执行：
mvn dependency:tree
这一步会立即输出整个项目的依赖层级。注意：默认只显示compile和runtime范围的依赖，test范围的不会出现——如果你正在调试测试失败问题，得额外加参数。
输出中每行开头的缩进代表依赖深度，+− 和 \− 符号区分同级兄弟节点，一眼就能看出哪个依赖是直接声明的、哪个是被A库带进来的、哪个又被B库覆盖掉了。
精准定位某个依赖的来源路径
方法一：用-Dincludes过滤出目标依赖
比如想查log4j-core到底被谁引入，且版本是不是你想要的：
mvn dependency:tree -Dincludes=org.apache.logging.log4j:log4j-core
方法二：用-Dexcludes排除干扰项
当树太长刷屏看不清时，先剔掉Spring全家桶这类高频大块头：
mvn dependency:tree -Dexcludes=org.springframework:*:*
【-Dincludes参数必须写全groupId:artifactId，不能只写groupId或只写artifactId】——漏掉任一部分，结果为空也不报错，你会误以为没这个依赖。
识别并确认依赖冲突
第一步：开启详细模式，让Maven标出被忽略的冲突项
mvn dependency:tree -Dverbose
第二步：在输出中搜索关键词 (omitted for conflict with) ——只要看到这串文字，就说明该行依赖因版本冲突被自动丢弃了。
第三步：对照前后两行，确认谁赢了（保留的版本）和谁输了（被omit的版本）。例如：
[INFO] +- org.springframework:spring-beans:jar:5.3.30:compile
[INFO] | \- org.springframework:spring-core:jar:5.3.30:compile
[INFO] \- org.springframework.boot:spring-boot-starter-web:jar:2.7.18:compile
[INFO] \- org.springframework:spring-core:jar:5.3.29:compile (omitted for conflict with 5.3.30)
→ 这说明spring-core 5.3.29被5.3.30顶替了，冲突发生在spring-boot-starter-web内部。
把依赖树存成文件慢慢分析
终端滚动太快记不住？直接导出为文本：
mvn dependency:tree -DoutputFile=deps.txt
文件会生成在当前目录下，用任意编辑器打开即可逐行搜索、高亮、做标记。比盯着终端回滚强十倍。
注意：如果文件已存在，命令会直接覆盖——别拿它存多个版本的树，容易误删。
检查是否存在循环依赖
第一步：执行带verbose参数的树命令并管道过滤
mvn dependency:tree -Dverbose | grep cycle
第二步：若输出为空，说明没有检测到循环；若出现类似“cycle detected: A → B → C → A”的提示，就得立刻去pom.xml里查这三个模块的dependency声明顺序和exclusion使用是否合理。
循环依赖不是编译期错误，但会在运行时引发ClassCircularityError，而且越晚暴露越难排查——这一步建议每周构建前顺手跑一次。
