定位冲突类来源需用mvn dependency:tree分析依赖路径，结合-dverbose:class观察jvm实际加载的jar，再通过exclusions精准排除传递依赖，并验证fat jar中目标类是否真实剔除。
怎么看哪个jar包引入了冲突的类
核心是定位来源——Maven不会告诉你ClassNotFoundException或NoClassDefFoundError具体来自哪个jar，但mvn dependency:tree能暴露依赖路径。运行时类加载失败，往往是因为两个不同版本的commons-collections4同时存在，而JVM只加载第一个遇到的。
实操建议：
- 加
-Dverbose参数看JVM实际加载路径：java -Dverbose:class -cp ... YourApp，注意输出里[Loaded org.apache.commons.collections4.ListUtils from file:/.../commons-collections4-4.1.jar]这一行 - 用
mvn dependency:tree -Dincludes=org.apache.commons:commons-collections4快速过滤特定坐标 - 如果树太深，加
-DmaxDepth=3限制层级，避免信息过载 - 留意
omitted for duplicate提示——它不等于“没加载”，只是Maven在展示时跳过了重复项，实际classpath里可能仍存在
怎么排除掉不需要的传递依赖
排除不是删jar，而是告诉Maven：“这个依赖链里，到我这儿就断掉”。写法必须精确到groupId:artifactId，漏一个冒号或拼错字母就无效。
实操建议：
- 在
<dependency></dependency>内部用<exclusions></exclusions>，不是在<dependencies></dependencies>顶层写 - 排除多个时，每个
<exclusion></exclusion>都要独立包裹<groupid></groupid>和<artifactid></artifactid>，不能合并 - 别排除自己直接声明的依赖（比如你写了
spring-boot-starter-web，却去排除它的spring-web），这会导致编译失败 - 排除后务必
mvn clean compile，IDE缓存常会假装排除生效了，其实没刷新
为什么exclude了还报NoClassDefFoundError
排除只影响Maven构建阶段的classpath生成，不影响运行时类加载器行为。常见原因是：某个被排除的jar，其class已被另一个未排除的依赖（比如guava）间接打包进fat jar，或被Spring Boot的loader机制提前加载。
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
实操建议：
- 检查是否用了
spring-boot-maven-plugin打包——它默认把所有依赖打进BOOT-INF/lib/，排除只影响编译，不删lib目录下的jar - 运行
jar -tf target/app.jar | grep collections确认目标类是否真被剔除 - 如果用
shaded插件重命名包（如org.apache.commons.collections4→shaded.org.apache.commons.collections4），要同步改代码里的import，否则编译不过 - 某些框架（如Log4j 2.x）会通过
ServiceLoader动态加载实现类，排除jar后，对应META-INF/services/文件也得一并处理
多模块项目里依赖冲突更难搞清
父POM声明的<dependencymanagement></dependencymanagement>只统一版本，不强制引入；子模块各自<dependencies></dependencies>叠加后，实际生效的版本由Maven的“最近定义原则”决定——不是最外层的parent，而是离当前module最近的那个声明。
实操建议：
- 在根POM的
<dependencymanagement></dependencymanagement>里用<scope>import</scope>导入BOM（如spring-boot-dependencies），比手动写几十个<version></version>更可控 - 子模块执行
mvn dependency:tree -f module-a/pom.xml，别只在根目录跑，否则看到的是聚合结果，不是单模块真实依赖 - 如果A模块排除了
slf4j-simple，但B模块又显式引入了它，且A依赖B，那A的classpath里依然会有slf4j-simple——排除不跨模块传递 - IDE里右键Maven → “Show Dependencies”有时比命令行树更直观，但记得点“Refresh”图标，否则显示的是旧快照
真正麻烦的从来不是排除动作本身，而是排除之后没人验证那个类是否还在运行时被其他路径悄悄加载。特别是用了自定义ClassLoader、OSGi、或者热部署工具（如JRebel）的项目，classloader隔离策略会让“排除”变成幻觉。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
