mvn dependency:tree -Dverbose才能显示被仲裁隐藏的冲突路径，多模块需逐子模块执行；<dependencyManagement>仅建议版本，子模块须省略<version>才生效；平台升级需同步插件、stater及Java版本；versions:use-latest-releases不检查兼容性，应改用display-dependency-updates人工验证。
依赖冲突时 mvn dependency:tree 看不出真实路径？
默认执行 mvn dependency:tree 会剪枝，隐藏被仲裁掉的冲突项，导致你以为没冲突，实际运行时报 NoClassDefFoundError 或方法找不到。必须加参数展开全量树：mvn dependency:tree -Dverbose。加上 -Dincludes=groupId:artifactId 可聚焦查看某个库（比如 -Dincludes=org.slf4j:slf4j-api），避免信息过载。
常见误区是只在根模块执行该命令——多模块项目中，每个子模块可能有独立依赖解析结果，必须进对应子模块目录下单独运行，否则看到的是父 POM 的聚合视图，不是该模块真实 classpath。
用 <dependencyManagement> 统一版本但子模块仍覆盖了？
<dependencyManagement> 只声明“建议版本”，不真正引入依赖；子模块若显式写 <version>（哪怕和父 POM 一致），就会绕过管理块的约束。真正生效的前提是：子模块中该依赖**省略 <version> 和 <scope>**（scope 若省略默认为 compile）。
检查点列表：
- 父 POM 的
<dependencyManagement>中是否包含<groupId>、<artifactId>、<version>三要素完整条目 - 子模块的
<dependencies>里对应依赖是否删掉了<version>标签 - 是否存在间接依赖（如 A→B→C）导致 C 的版本由 B 的 pom 决定，而非父 POM 管理——这时需在
<dependencyManagement>中强制指定 C 的版本
升级一个公共组件（如 Spring Boot）却引发子模块编译失败？
Spring Boot、Quarkus 这类平台型依赖，升级不只是改 <version>，还涉及插件版本、starter 兼容性、甚至 Java 版本要求变化。例如从 Spring Boot 2.7 升到 3.2，必须同步升级 maven-compiler-plugin 到支持 Java 17+，且所有 spring-boot-starter-* 必须与主版本对齐，否则 Maven 会拉取旧版 starter 导致 Bean 注册异常。
实操建议：
- 先查官方迁移指南（如
https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-3.0-Migration-Guide），重点关注 breaking changes 小节 - 在父 POM 中统一用
<properties>定义平台版本变量（如<spring-boot.version>3.2.5</spring-boot.version>），子模块通过${spring-boot.version}引用，避免硬编码 - 升级后务必在每个子模块执行
mvn clean compile，不能只在根目录跑mvn compile——后者跳过部分子模块的编译校验
为什么 mvn versions:use-latest-releases 不推荐用于生产项目？
这个插件会自动把所有依赖升到最新 release 版本，但它不理解语义化版本规则，也不检查兼容性。比如把 junit-jupiter 从 5.9.x 升到 5.10.x 可能没问题，但若误把 net.bytebuddy 从 1.12.x 升到 1.14.x，而当前使用的 Mockito 4.11 仅适配到 1.12.x，就会导致 mock 失败且错误堆栈极难定位。
更稳妥的做法是：
- 用
mvn versions:display-dependency-updates查看可升级项，人工比对变更日志 - 对核心基础库（如 SLF4J、Guava、Jackson）坚持“小步快跑”：一次只升一个主版本，配合集成测试验证
- 把
versions-maven-plugin配置成仅检查特定 groupId（如<includes>com.fasterxml.jackson.*</includes>），避免全局误触
多模块项目里，依赖治理不是设好 <dependencyManagement> 就一劳永逸的事——每个子模块都是独立的 classpath 上下文，版本决策必须落到具体模块的 pom.xml 层级，且每次升级都要验证其直接和传递依赖的实际加载行为。
