ClassLoader本身不解决版本冲突，而是通过类加载器隔离机制使不同ClassLoader加载的同名类视为独立类型，其唯一性由“全限定名+ClassLoader实例”共同决定。
ClassLoader 本身不解决“依赖变量库版本冲突”，它只是提供了一种机制，让不同版本的同名类可以共存——前提是它们由不同的类加载器实例加载。真正起作用的是“类加载器隔离”策略，而非 ClassLoader 这个抽象概念本身。
核心原理：类的唯一性由“全限定名 + 类加载器实例”共同决定
Java 规定：两个类即使字节码完全相同、包名类名一致，只要加载它们的 ClassLoader 实例不同，JVM 就视其为两个独立类型，互不兼容。这意味着：
- 同一个 ClassLoader 不会重复加载同一个类（双亲委派下首次加载即锁定）
- 不同 ClassLoader 可各自加载自己版本的
com.google.common.base.Preconditions - 但 A 类用 CL1 加载的 Preconditions 调用 B 类时，B 若由 CL2 加载且也依赖 Preconditions，则必须确保 B 内部使用的也是 CL2 加载的同一份——否则会出现
ClassCastException或NoSuchMethodError
可行的隔离策略与适用场景
不是所有项目都适合手动管理 ClassLoader，需结合部署环境判断：
- 插件化系统（如 IDE、报表引擎、规则引擎）：每个插件使用独立的 URLClassLoader 加载自身 JAR，天然隔离；主程序不直接 new 插件类，而是通过反射或接口代理调用
- Web 容器（Tomcat/Jetty）：WebAppClassLoader 隔离每个应用的 /WEB-INF/lib，避免应用间冲突；但要注意 shared lib 与应用 lib 中同名类的加载优先级
- OSGi 框架：模块（Bundle）级类加载隔离，支持版本共存和动态启停，但侵入性强、学习成本高
-
自定义 ClassLoader + 接口契约：对外暴露统一接口（如
Processor），内部实现由不同 ClassLoader 加载不同版本依赖；调用方只依赖接口，不感知具体实现类路径
关键注意事项：不能只换加载器，还要管住“线程上下文”和“静态依赖”
常见误区是仅设置 Thread.currentThread().setContextClassLoader() 就以为切换了环境——这仅影响后续由该线程触发的、显式使用 Thread.currentThread().getContextClassLoader() 的加载行为，不影响：
- 已加载的类中静态字段、静态代码块（初始化后不可逆）
- main 方法所在类及其直接引用的类（由 AppClassLoader 固定加载）
- 第三方库内部硬编码的 ClassLoader 获取方式（如
MyClass.class.getClassLoader()） - 反射调用时未显式指定 ClassLoader，可能沿用调用方的加载器
更务实的替代方案（多数业务项目首选）
比起手写 ClassLoader，优先考虑构建期控制：
- 用
<exclusions></exclusions>显式排除传递依赖中的冲突版本 - 在
<dependencymanagement></dependencymanagement>中统一声明关键依赖（如 Guava、Jackson、Netty）的兼容版本 - 对必须并存的多版本库，采用 Shading（重命名包路径），例如 Maven Shade Plugin 的
<relocation></relocation>配置 - 升级到 Spring Boot 3.x / Jakarta EE 9+ 等生态较新版本，减少老旧中间件引发的隐式冲突
ClassLoader 隔离是底层能力，不是银弹。它有效但复杂，容易引入类泄漏、序列化失败、调试困难等问题。除非架构明确需要运行时动态加载/卸载模块，否则应优先用依赖管理工具从源头收敛版本。
