模块化类加载隔离需为每个模块配专属classloader并确保同名类由不同加载器加载，jvm仅认“类全名+classloader实例”；须通过spi接口契约隔离、切断隐式引用、管控线程上下文，并用arthas或-verbose:class验证隔离效果。
模块化下的类加载隔离不是靠“换一个加载器”就自动生效，关键在于让同名类被不同类加载器加载，且调用链不跨边界。jvm 本身不识别“模块版本”，只认“类全名 + 加载它的 classloader 实例”——两者任一不同，就是两个完全无关的类型。
明确隔离边界：每个模块配专属 ClassLoader
不能依赖默认的 AppClassLoader 统一加载所有模块，否则同名类必然冲突。必须为每个可能存在版本差异的模块（如插件、扩展包、独立服务组件）创建独立的 ClassLoader 实例：
- 推荐使用 URLClassLoader 或其子类，传入该模块专属的 JAR/目录路径
- 避免设置父加载器为系统类加载器（除非明确需要共享基础类），可设为
null或自定义的“共享基础加载器” - 确保模块内所有依赖（包括 transitive 依赖）都由同一 ClassLoader 加载，不要混用
切断隐式跨加载器引用：只走接口，不碰实现类
即使类被隔离了，一旦某处代码直接 new 了另一个模块的实现类，或强转为对方加载的类型，就会触发 ClassCastException。必须用契约隔离：
- 定义统一的 SPI 接口（如
Processor、RuleEngine），放在公共模块，由启动类加载器或共享 ClassLoader 加载 - 各模块只提供该接口的实现，但实现类本身由各自 ClassLoader 加载
- 主程序通过反射或工厂方法获取实例时，仅持有接口引用，绝不强转为具体实现类
管住线程上下文与静态依赖
很多人设了 Thread.currentThread().setContextClassLoader() 就以为万事大吉，其实远远不够：
- 已加载的类中静态字段、静态代码块不会重执行，其内部使用的 ClassLoader 是初始化时固定的
- 第三方库若写死
MyClass.class.getClassLoader()，它拿到的是自己类的加载器，不是你刚设的上下文加载器 - 动态加载后首次调用前，需确保当前线程的上下文 ClassLoader 已切换，并在调用结束后及时还原（尤其在线程池场景）
验证是否真正隔离：用 Arthas 或 -verbose:class 看加载源头
光看代码逻辑不够，得确认运行时 JVM 真的加载了你期望的类：
- 启动时加
-verbose:class，观察同名类（如com.example.Config）是从哪个路径、由哪个 ClassLoader 加载的 - 生产环境用 Arthas 的
sc -d com.example.Config查看类详情，确认classLoaderHash是否不同 - 若发现两个模块的同名类 hash 相同，说明没隔离成功，要回溯加载路径和 ClassLoader 构建逻辑
