maven不存在依赖死锁，循环依赖会导致构建失败；需用mvn dependency:tree排查依赖冲突、版本覆盖等问题，结合-dincludes、-dverbose等参数精准定位并修复。
Java Maven 中没有“依赖死锁”这个概念——Maven 本身不支持循环依赖，遇到循环依赖会直接构建失败并报错（如 A depends on B, B depends on A），而不是陷入“死锁”。真正需要排查的是依赖冲突、版本覆盖、重复引入、传递依赖干扰等问题，而 mvn dependency:tree 正是定位这类问题的核心工具。
精准过滤，聚焦可疑依赖
默认输出的依赖树太长，容易淹没关键信息。建议用 -Dincludes 或 -Dexcludes 缩小范围：
-
查某个库的所有路径：
mvn dependency:tree -Dincludes=org.slf4j:slf4j-api -
排除测试相关干扰：
mvn dependency:tree -Dscope=compile（只看编译期依赖） -
高亮冲突项：
mvn dependency:tree -Dverbose，它会标出被仲裁（omitted for conflict）的版本
识别并理解版本仲裁结果
Maven 按最近优先（nearest definition）原则选择版本。如果 tree 中某依赖显示为 omitted for conflict，说明它被更高层或更近路径的同名依赖覆盖了：
- 例如：A → B → C:1.0，同时 A → D → C:2.0，则 C:1.0 会被 omit，实际使用 C:2.0
- 用
-Dverbose可看到完整路径和被裁剪原因，再结合pom.xml中的<dependencymanagement></dependencymanagement>判断是否被统一锁定
结合 -Dverbose + -Dincludes 定位冲突源头
当运行时报 NoClassDefFoundError 或 NoSuchMethodError，大概率是类/方法因版本不匹配丢失。此时组合命令最有效：
mvn dependency:tree -Dverbose -Dincludes=com.fasterxml.jackson.core:jackson-databind- 观察所有出现路径，检查哪个版本被保留、哪些被 omit，再比对运行时实际加载的 jar（可通过
ClassLoader.getSystemResource("...")或 IDE 的 “Jump to Source” 验证）
验证修复效果：用 -DforceVersion 强制指定（临时调试用）
若怀疑某依赖版本不对，可临时强制其版本（仅用于验证，非长期方案）：
- 在命令行加参数：
mvn compile -Ddependency.locations.enabled=false -DforceVersion=2.15.2（需配合插件配置） - 更稳妥做法是在
pom.xml的<dependencymanagement></dependencymanagement>中显式声明目标版本，再重新跑dependency:tree确认生效
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
