核心是控制“谁先被看到”，而非事后排查；jvm按classpath顺序加载类，同名类一旦被加载后续即失效；需通过-verbose:class、arthas或getresource定位实际来源；构建期用dependencymanagement、exclusions和mvn dependency:tree规范依赖顺序；运行时避免共享目录干扰，ide中调整依赖顺序；版本冲突时用urlclassloader隔离并重写loadclass。
核心是控制“谁先被看到”，而不是等冲突发生后再排查。JVM 类加载走的是类路径（classpath）顺序扫描机制，同名类一旦被某个 ClassLoader 加载，后续同名类就彻底失效——这不是优先级高低问题，而是加载次序的确定性问题。
确认实际加载来源
运行时必须知道哪个 jar 真正提供了出问题的类：
- 启动时加 -verbose:class 参数，观察报错类首次出现的 jar 路径，例如：
[Loaded org.springframework.core.io.Resource from file:/app/lib/spring-core-5.2.9.jar] - 线上环境用 Arthas 快速验证：
sc -d com.xxx.Yyy查加载位置，sm com.xxx.Yyy *看实际方法列表，对比是否缺失目标 API - Web 应用中可临时写一行代码：
YourClass.class.getResource("YourClass.class").toString()，直接输出该类所在 jar 的完整路径
从构建期锁定顺序
避免把问题留给运行时，关键依赖要在打包前就排好队：
- Maven 中用
统一声明 BOM（如 spring-framework-bom），强制所有模块使用同一套版本 - 对已知冲突的传递依赖，显式
排除，不给它混入 classpath 的机会 - 执行
mvn dependency:tree -Dverbose，识别重复引入路径；把更合理、更新的依赖声明往前挪——Maven 按 pom 中声明顺序做仲裁 - Spring Boot fat jar 默认按字母序加载 BOOT-INF/lib/ 下的 jar，可通过 Maven 插件重命名关键 jar（如
001-spring-core-5.3.30.jar）确保靠前
运行时保障加载确定性
即使构建干净，容器或部署环境仍可能干扰 classpath 顺序：
- Web 应用务必把核心 jar 放在 WEB-INF/lib/ 目录下，不要放在 Tomcat/lib 或 shared/lib 这类共享目录，避免被 CommonClassLoader 提前加载
- IDE 中调整依赖顺序：IntelliJ → Project Structure → Modules → Dependencies，把目标 jar 拖到顶部；Eclipse → Build Path → Order and Export，勾选并上移
- 生产环境可启用 -XX:+TraceClassLoadingPreorder（HotSpot 支持），获取精确的类加载候选顺序，辅助验证策略是否生效
当版本无法统一时做隔离
如果两个模块确实需要不同版本的同一 jar（如插件场景），不能靠删包解决，而要打破默认加载模型：
- 为每个模块创建独立的 URLClassLoader，构造时传入
null作为 parent，切断双亲委派 - 重写
loadClass方法：对白名单包（如com.mysql.）优先调用findClass，其余仍走委派，兼顾安全与隔离 - 注意资源释放：加载完成后及时释放 ClassLoader 实例引用，防止 Class 对象长期驻留引发内存泄漏
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
