Maven 依赖传递如何工作？冲突版本该怎么排查？

Maven 依赖传递的意思是：你的项目依赖 A，而 A 又依赖 B，那么 B 通常会自动进入你的项目 classpath。这个机制省掉了大量手工拷 jar 的工作，但也会带来版本冲突、重复依赖和运行时类不兼容。排查 Maven 依赖问题时，不要先猜哪个 jar 错了，先看依赖树。

Maven 决定冲突版本时主要看两个规则：路径近的优先，路径一样近时先声明的优先。比如项目同时通过两条路径引入 guava:30 和 guava:32，Maven 只会选一个版本进入最终依赖。这个选择不一定符合业务预期，所以大型项目通常会用父 POM 或 BOM 统一锁版本。

bash
mvn dependency:tree
mvn dependency:tree -Dincludes=com.google.guava:guava
mvn dependency:analyze

排查依赖冲突的顺序

依赖冲突不要从删除 jar 开始，应该先确定最终 classpath 里到底用了哪个版本。第一步看 mvn dependency:tree，确认冲突依赖来自哪条路径；第二步看业务报错，是编译期缺类、运行时缺方法，还是类重复导致的加载问题；第三步再决定是直接声明版本、使用 dependencyManagement，还是对某个上游依赖做 exclusion。

版本统一也不是越新越好。安全漏洞修复通常要求升级，但框架生态会对版本组合有约束，例如 Spring Boot 管理的 Jackson、Netty、Logback 版本最好优先跟随官方 BOM。强行把其中一个依赖单独升到很新的版本，短期能过扫描，长期可能引入二进制兼容问题。

在库项目里尤其要注意依赖暴露。你的公共 API 如果返回了某个第三方类型，下游就被迫感知这个依赖版本；如果只是内部实现使用，尽量不要让它泄漏到 API 签名中。这个边界处理不好，依赖冲突会从一个项目扩散到所有使用方。

还有一种隐蔽问题是依赖范围带来的传递差异。上游把某个库标成 optional 或 provided，下游可能并不会自动拿到它。此时不要盲目责怪 Maven，先确认这个依赖到底是不是上游希望暴露给你的运行时依赖。这类依赖最好在模块说明里写清楚，否则使用方很难判断该不该自己声明版本。

追问

Maven 解决依赖冲突时为什么是“最近优先”？

最近优先可以让直接依赖更容易表达项目意图，因为离当前项目越近，通常越能代表当前项目真正需要的版本。它的好处是规则简单、可预测，坏处是版本选择可能被某个中间依赖无意改变。比如新增一个 starter 后，依赖路径变短，最终使用的日志库版本就可能变了。踩坑时不要只看 pom.xml 的直接依赖，要用依赖树确认最终生效版本。

dependencyManagement 能不能直接引入依赖？

不能，它只负责管理版本和范围，不会把依赖自动加入项目。子模块仍然需要在 <dependencies> 中声明 groupId 和 artifactId，才会真正使用这个依赖。这个设计的取舍是牺牲一点书写便利，换来模块依赖边界清晰。常见错误是只在父 POM 的 dependencyManagement 里加了版本，然后发现代码里还是找不到类。

xml
<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>com.google.guava</groupId>
      <artifactId>guava</artifactId>
      <version>33.2.1-jre</version>
    </dependency>
  </dependencies>
</dependencyManagement>

什么时候该用 exclusions 排除传递依赖？

当某个传递依赖明确不应该进入当前项目，或者它引入了冲突版本时，可以用 <exclusions>。但排除依赖不是越多越好，因为你可能把上游库运行时真正需要的类排掉，最后变成 ClassNotFoundException。更稳的做法是先用依赖树确认来源，再排除具体坐标，而不是大面积排掉一组库。边界是安全类、日志实现、旧版 JSON 库这类常见冲突点适合谨慎排除。

xml
<dependency>
  <groupId>com.example</groupId>
  <artifactId>legacy-sdk</artifactId>
  <version>1.0.0</version>
  <exclusions>
    <exclusion>
      <groupId>commons-logging</groupId>
      <artifactId>commons-logging</artifactId>
    </exclusion>
  </exclusions>
</dependency>

BOM 和父 POM 管版本有什么区别？

父 POM 可以管理依赖版本、插件版本、属性和构建配置，适合公司内部统一工程规范。BOM 通常只通过 import scope 导入一批依赖版本，适合 Spring Boot、Spring Cloud 这类生态统一版本矩阵。取舍上，如果你只想复用版本，不想继承别人的插件和构建约定，BOM 更轻。踩坑点是多个 BOM 同时导入时，顺序会影响相同依赖的最终版本。

依赖冲突一定会在编译期暴露吗？

不一定，很多冲突只会在运行时出现，例如 NoSuchMethodError、NoClassDefFoundError 或序列化行为异常。编译期只说明当前源码能找到方法，不代表运行时加载的 jar 版本完全匹配。边界在于 Java classpath 最终只加载一个同名类，多个版本并存时谁先生效会影响结果。生产事故里最怕的就是测试环境和线上依赖树不同，所以发布前最好在 CI 中固定 Maven 版本、仓库源和构建参数。