mvn dependency:tree 是解决冲突的第一步，因其能揭示真实依赖结构、显示被仲裁忽略的版本、定位间接引入源，并为精准 exclusion 和 dependencymanagement 提供依据。
为什么 mvn dependency:tree 是解决冲突的第一步
Maven 的依赖传递机制会让一个项目实际加载的 JAR 远多于 pom.xml 显式声明的数量。包冲突（比如两个不同版本的 guava 同时被拉入）往往不会立刻报错，而是在运行时出现 NoClassDefFoundError 或 NoSuchMethodError —— 此时靠猜没用，必须看真实依赖结构。
- 直接执行
mvn dependency:tree -Dverbose，-Dverbose能显示被忽略/被裁剪的节点，否则可能漏掉隐藏冲突源 - 加上
-Dincludes=org.apache.commons:commons-lang3可聚焦查看某库的完整路径，快速定位是谁间接引入了旧版 - 注意输出中带
omitted for conflict with X.X.X的行——这说明 Maven 已自动做了仲裁，但未必是你想要的结果
用 <exclusion></exclusion> 精准切断不需要的传递依赖
Maven 默认按“最短路径优先”仲裁版本，但有时短路径引入的是不兼容旧版（如 spring-boot-starter-web 带的 tomcat-embed-core 9.0.83 和你项目需要的 10.1.24 冲突），这时不能只靠升级 starter，得主动排除。
- 在对应依赖块内加
<exclusions></exclusions>，例如排除logback-classic避免和slf4j-simple混用：<dependency><groupid>org.springframework.boot</groupid><artifactid>spring-boot-starter-web</artifactid><exclusions><exclusion><groupid>ch.qos.logback</groupid><artifactid>logback-classic</artifactid></exclusion></exclusions></dependency>
-
<exclusion></exclusion>中的<groupid></groupid>和<artifactid></artifactid>必须完全匹配依赖树里显示的值，大小写、连字符都不能错 - 排除后记得在
pom.xml顶层显式声明你需要的版本，否则该类库可能彻底消失
dependencyManagement 块不是可选项，而是多模块项目的控制中枢
单模块项目靠 <properties></properties> 定义版本号还能凑合，一旦有 common、service、api 多个子模块，各模块各自声明同一依赖的不同版本，构建就会不可控。
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 在父 POM 的
<dependencymanagement></dependencymanagement>中统一锁定版本，子模块只需写<groupid></groupid>和<artifactid></artifactid>，不用写<version></version>和<scope></scope> - 注意：
<dependencymanagement></dependencymanagement>不引入依赖，只是“声明规则”，子模块仍需在自己的<dependencies></dependencies>中声明才生效 - 如果子模块需要覆盖父级管理的版本（极少数情况），必须在子模块自己的
<dependencymanagement></dependencymanagement>中重新定义，且要确保它在继承链中更靠近叶子节点
运行时 ClassLoader 问题比编译期更难排查
Maven 解决了构建时的 JAR 一致性，但 Spring Boot 的嵌套 JAR 结构、自定义 ClassLoader（如某些 SDK 的插件机制）、甚至 IDE 的热替换逻辑，都可能导致类加载顺序与 dependency:tree 显示不符。
- 启动时加 JVM 参数
-verbose:class，观察具体哪个 JAR 加载了org.slf4j.Logger这类关键类 - 在代码中打印
Logger.class.getProtectionDomain().getCodeSource().getLocation()，确认实际加载来源 - 使用
mvn clean compile后检查target/classes/META-INF/maven/下各依赖的pom.properties，验证打包时是否真用了预期版本
真正麻烦的从来不是“怎么排除”，而是“排除之后谁来提供这个类”。很多 NoClassDefFoundError 表面是缺类，实则是某个被排除的依赖本该提供 SPI 实现或静态工具方法——得顺着异常栈往回查三到四层，再比对 dependency tree 里对应路径的完整版本链。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
