Maven依赖仲裁遵循两大确定性规则：路径最短优先，即选择从项目根到依赖节点跳数最少的版本；路径相同时按pom.xml中dependencies内声明顺序优先，先声明者胜出。
Java 项目里依赖一多，Maven 就会自动帮你“选版本”，靠的是两个硬性规则：路径最短的优先，路径一样长就看谁在 pom.xml 里写在前面。这不是猜测或经验判断，而是 Maven 内置的确定性逻辑，理清依赖树的关键就是理解并利用好它。
看清真实依赖结构：用 dependency:tree 抓住隐藏冲突
光看 pom.xml 声明的依赖远远不够——大量 jar 是间接引入的。必须执行命令查看实际构建时的依赖树：
-
基础查看：
mvn dependency:tree显示默认裁剪后的树，简洁但可能漏掉被仲裁掉的版本 -
显示所有分支（含被忽略项）：
mvn dependency:tree -Dverbose，输出中带 omitted for conflict with X.X.X 的行，就是被短路径规则干掉的旧版，正是冲突源头 -
聚焦某个库查来源：
mvn dependency:tree -Dincludes=org.springframework:spring-core，快速定位是哪个 starter 或中间件偷偷拉进了不兼容的老版本
短路径优先：不是“谁先出现”，而是“谁离项目根最近”
这个规则决定绝大多数版本选择。Maven 从你的项目模块（root）出发，计算到达每个依赖的跳数（边数），跳数越少，版本越“有话语权”。
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 例如：你的项目 → spring-boot-starter-web → tomcat-embed-core 9.0.83（2跳）
同时：你的项目 → your-utils-lib → guava 19.0 → tomcat-embed-core 10.1.24（3跳）
→ 最终生效的是 9.0.83，因为路径更短 - 注意：路径长度只算直接依赖链，不看 jar 包体积或功能强弱；也不受 groupId 是否相同影响，只认坐标（groupId:artifactId）唯一性
路径相同时，声明顺序起决定作用
当两个不同版本的同一依赖，通过等长路径抵达（比如都是 2 跳），Maven 就按你在 <dependencies> 里写的先后顺序来拍板。
立即学习“Java免费学习笔记（深入）”；
- 若 pom 中先写
<dependency><artifactId>guava</artifactId><version>32.1.3-jre</version></dependency>，后写另一个含 guava 30.1.1 的 starter，则最终用 32.1.3 - 这个规则从 Maven 2.0.9 起稳定生效；老版本（如 2.0.8 及之前）不保证顺序可靠，务必升级
- 声明顺序只影响
<dependencies>块内显式声明的依赖，不影响<dependencyManagement>中的统一管理
主动干预仲裁结果：exclusion 和 dependencyManagement 是关键工具
默认规则有时会选错——比如短路径带进来的是不兼容的旧版。这时不能等 Maven 自己改主意，得手动干预：
-
精准切断传递依赖：在引入有问题的 starter 时，用
<exclusion>去掉它自带的冲突 jar
例如：<exclusion><groupId>com.google.guava</groupId><artifactId>guava</artifactId></exclusion> -
全局锁定版本：在
<dependencyManagement>中统一指定版本，所有子模块/传递依赖都会服从该版本，覆盖短路径和声明顺序的影响 - 注意：
<exclusion>不是删除，而是阻止传递；排除后若其他路径仍引入同名 jar，仲裁规则继续生效——所以常需配合<dependencyManagement>确保最终版本可控
