ClassLoader 隔离通过类加载器+全限定名双重唯一性实现多版本库共存，需打破双亲委派、依赖接口契约解耦，并防范线程上下文与静态变量穿透风险。
ClassLoader 隔离机制本身不直接“解决”变量库版本冲突，而是通过让不同版本的类在 JVM 中成为互不兼容的独立类型，从而实现多版本变量库（如不同版本的 Guava、Jackson、MySQL 驱动等）安全共存。关键不在“变量”，而在“加载它的类”是否被隔离。
类唯一性是隔离的根本前提
Java 规定：一个类的运行时身份由全限定名 + 加载它的 ClassLoader 实例
- 哪怕两个 JAR 中的
com.google.common.base.Preconditions字节码完全一样，只要被不同的 ClassLoader 加载，JVM 就视其为两个类； - 它们各自的静态变量（如
Preconditions.checkArgument内部状态）、常量池、方法表、字段内存地址全部独立； - 模块 A 中调用
Preconditions不会影响模块 B 中同名类的任何行为，也不会引发ClassCastException或NoSuchMethodError——前提是调用链不跨加载器混用。
必须切断双亲委派才能真正隔离
默认双亲委派会让所有请求最终落到 AppClassLoader，导致多个版本被统一加载。要实现版本共存，需主动打破该链：
- 新建
URLClassLoader时传入null作为 parent，彻底隔绝系统类加载器影响； - 重写
loadClass(String, boolean)，优先调用findClass()从指定路径（如/libs/mysql-5.1/）加载，仅在失败时才委托； - 避免使用
Class.forName(name)这类依赖上下文类加载器的方法，改用classLoader.loadClass(name)显式指定加载器。
接口契约是跨版本调用的安全桥梁
不同 ClassLoader 加载的实现类无法直接强引用，必须靠抽象层解耦：
- 定义公共接口（如
DataProcessor）由系统类加载器（AppClassLoader）加载，确保所有模块都看到同一份定义； - 各版本实现类（
MySql51Processor、MySql80Processor）分别由各自 ClassLoader 加载； - 调用方只持有
DataProcessor接口引用，通过反射或工厂方法获取实例，不感知具体类名与路径。
实际部署中要注意线程与静态依赖的穿透风险
仅切换 Thread.currentThread().setContextClassLoader() 并不能保证全程隔离：
- 第三方库若内部硬编码调用
Class.forName("xxx")，仍会走默认上下文加载器，可能意外加载错误版本； - 静态工具类（如
StringUtils）若被多个模块共享且未做加载器适配，其静态字段可能被某一方修改，影响其他模块； - 建议将隔离模块封装为独立插件或服务单元，限制其类路径范围，并禁用跨模块对象直传（如禁止把 v5.1 的
Connection实例传给 v8.0 模块处理）。
