多版本插件物理隔离需路径分离与独立类加载器并行：按组件+版本建目录（如/plugins/kafka/0.10/），每个版本用专属PluginClassLoader实例绑定路径，重写loadClass实现本地优先加载，并通过系统类加载器加载统一接口实现跨版本调用。
在复杂模块化架构中，实现多版本插件的物理隔离，关键不是把类“藏得更深”，而是让每个版本拥有专属的加载路径和独立的加载器实例——路径决定字节码来源，实例决定类型身份，二者缺一不可。
为每个插件版本分配独立的类加载路径
物理隔离的第一步是目录级分离。不能把所有插件 JAR 放进同一个文件夹，而应按组件+版本维度建模路径：
- /plugins/kafka/0.10/ —— 存放 kafka-clients-0.10.x.jar 及其全部依赖（如 slf4j-api、netty）
- /plugins/kafka/3.5/ —— 存放 kafka-clients-3.5.x.jar 及配套依赖（可能含新版 jackson-databind）
- /plugins/mysql/5.1/ 和 /plugins/mysql/8.0/ 同理，各自封闭打包
路径本身不产生隔离，但它为后续加载器指明了唯一字节码来源，避免 findClass 时误读其他版本的类。
用独立 ClassLoader 实例绑定专属路径
定义一个 PluginClassLoader 类只是模板；真正起作用的是每次 new 出来的新实例：
- 错误做法：全局复用一个 loader 实例，反复调用 addURL() 切换路径 → 所有版本挤在同一命名空间
-
正确做法：每个插件启动时创建新实例，构造时传入对应路径：
new PluginClassLoader(Paths.get("/plugins/kafka/0.10").toUri()) - JVM 会将 该实例 + com.example.KafkaProducer 视为一个完整类型标识，与 /kafka/3.5 下同名类完全无关
重写 loadClass 实现“本地优先、委托兜底”
默认双亲委派会把请求一路推给 AppClassLoader，导致 v0.10 的类被 v3.5 的环境污染。必须切断这一链路：
- 覆盖
loadClass(String name, boolean resolve)方法 - 第一步查缓存：
findLoadedClass(name)，命中则直接返回 - 第二步本地加载：
findClass(name)仅从本实例绑定路径读取字节码 - 第三步仅当 findClass 明确抛出
ClassNotFoundException时，才调super.loadClass委托（通常留给 java.*、javax.* 等核心类）
这样既保证插件内部依赖不外溢，又不破坏 JVM 基础运行能力。
接口与实现分层加载，打通跨版本调用
隔离不是为了割裂，而是为了安全共存。调用方需依赖统一契约，而非具体实现：
- 定义
MessageService接口，打包进主程序，由系统类加载器（AppClassLoader）加载 - v0.10 插件中的
MessageServiceImpl由其专属 PluginClassLoader 加载 - 通过
Class.forName("com.example.MessageServiceImpl", true, v010Loader)获取类对象，再newInstance()创建实例 - 最后强制转型为
MessageService接口 —— 因为接口来自系统加载器，所有插件都认这个“共同语言”
这种分层让不同版本插件可被同一套调度逻辑管理，无需修改宿主代码。
