Maven依赖冲突解决的核心是依赖调解机制，按“最短路径优先”和“声明顺序优先”自动选版本；可通过<exclusions>排除传递依赖或<dependencyManagement>统一锁定版本，并用mvn dependency:tree验证。
Java 中使用 Maven 的依赖传递与依赖冲突解决机制，关键不是“用不用”，而是“怎么让它们按你预期工作”。Maven 默认会自动传递依赖、自动仲裁版本，但一旦结果不符合实际需要（比如运行时报 NoSuchMethodError、日志框架不生效、JSON 序列化异常），就说明传递或仲裁出了问题——这时必须理解机制、主动干预。
依赖传递：它自动发生，但你能控制边界
当你声明一个依赖（如 spring-boot-starter-web），Maven 会拉取它所声明的所有 compile 范围的依赖（比如 spring-web、jackson-databind、嵌入式 tomcat），这叫依赖传递。它省去手动写一堆底层 jar 的麻烦，但也埋下冲突隐患。
-
传递不是无条件的：只有
scope=compile（默认）的依赖才会被传递；provided或test不会传给下游项目。 -
可选依赖（optional=true）会切断传递链：如果 A 声明 B 为
<optional>true</optional>，那么引入 A 的项目不会自动得到 B，除非自己显式声明。 -
排除干扰项用
<exclusions>：比如部署到外部 Tomcat 时，可排除内嵌容器：
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
<exclusions>
<exclusion>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-tomcat</artifactId>
</exclusion>
</exclusions>
</dependency>
依赖冲突：不是 bug，是路径与声明的博弈
冲突本质是同一个 groupId:artifactId 出现多个版本。Maven 不报错，而是按规则选一个——但选出来的未必是你想要的。典型场景：你写了 okio:2.8.0，最终却加载了 2.10.0，就是因为另一条依赖路径更短或声明更靠前。
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 最短路径优先：A → B → C-2.0（路径长 2）胜过 A → D → E → C-1.0（路径长 3）。
- 路径相同时，先声明者胜：若 A 直接依赖 C-1.0 和 C-2.0（都是一级依赖），则 pom 中靠前的那个生效。
- 不会自动选高版本：Maven 不按数字大小选，只看路径和顺序。2.0 不一定比 1.9 “赢”。
定位冲突：别猜，用命令看真实依赖树
光看 pom 写了什么没用，得看 Maven 实际解析出的结构：
立即学习“Java免费学习笔记（深入）”；
-
mvn dependency:tree：输出完整依赖树，带缩进层级；加-Dverbose显示被省略的重复项。 -
mvn dependency:tree -Dincludes=commons-collections：聚焦查看某个坐标，快速定位谁带进了哪个版本。 -
mvn dependency:analyze：检查未使用的直接依赖（可能隐藏着冗余冲突源）。
解决冲突：从局部排除到全局锁定
小范围问题用 <exclusions> 快速切掉干扰项；中大型项目务必用 <dependencyManagement> 统一版本，避免各模块各自声明导致不一致。
-
用
<dependencyManagement>锁定版本：在父 pom 或当前 pom 的<dependencyManagement>块中声明logback-classic、jackson-core等基础组件版本，所有子模块引用时无需写<version>，也不会被传递依赖覆盖。 -
注意 scope 影响仲裁结果：比如
test范围的依赖不会参与 runtime 冲突仲裁，但可能影响编译期行为。 -
验证是否生效：改完后务必再跑一次
mvn dependency:tree，确认目标 jar 只出现你指定的那一个版本。
