插件化架构通过独立类加载路径与专属classloader实例实现隔离：按“组件+版本”分目录存放jar，每个插件启动时新建classloader绑定对应路径，重写loadclass实现本地优先加载，并依托统一接口契约跨插件调用。
插件化架构中用 JVM 类加载器实现隔离，关键在于让每个插件拥有独立的类加载路径和专属的类加载器实例——路径决定字节码来源，实例决定类型身份，二者缺一不可。
按“组件+版本”组织物理目录结构
不能把所有插件 JAR 放进同一文件夹。必须严格按“组件名+版本号”维度划分目录，例如：
- /plugins/kafka/0.10/：存放 kafka-clients-0.10.x.jar 及其私有依赖（如 netty-3.10、slf4j-api-1.7）
- /plugins/kafka/3.5/：存放 kafka-clients-3.5.x.jar 及配套依赖（可能含 jackson-databind-2.15）
- /plugins/mysql/5.1/ 和 /plugins/mysql/8.0/ 同理，各自封闭打包，互不交叉
目录本身不产生隔离，但它为后续类加载器提供了唯一、可绑定的字节码来源，避免 findClass 时误读其他版本的类。
为每个插件创建独立 ClassLoader 实例
重点不是写一个 PluginClassLoader 类，而是在每次启动插件时 new 出一个新实例：
- 错误做法：全局复用一个 loader 实例，反复 addURL() 切换路径 → 所有版本挤在同一命名空间
- 正确做法：kafka v0.10 启动时 new PluginClassLoader(Paths.get("/plugins/kafka/0.10").toUri())；v3.5 启动时 new 另一个新实例绑定 /kafka/3.5 路径
JVM 将“类全限定名 + 加载器实例”视为完整类型标识。因此 com.example.KafkaProducer 在 v0.10 加载器下和在 v3.5 加载器下，是两个完全无关、无法赋值、无法强转的类。
重写 loadClass 实现本地优先加载
默认双亲委派会先委托父加载器，这会导致插件类被系统类加载器提前加载，破坏隔离。需显式打破委派链：
- 重写 loadClass(String name, boolean resolve)，不调用 super.loadClass
- 先尝试用 findClass(name) 从本插件路径加载
- 仅对基础类型（如 java.lang.String、java.util.List）或约定共享接口，才向上委派给父加载器
这样既保证插件内部类自洽，又避免重复加载核心类引发冲突。
通过接口契约实现跨插件安全调用
插件之间不能直接传实现类对象，必须依赖统一定义的接口：
- 将插件共用的 API 抽成独立模块（如 plugin-api.jar），由系统类加载器加载
- 各插件只实现该接口，不暴露具体类名
- 宿主程序通过接口类型接收插件实例，运行时实际调用的是对应加载器下的实现
例如 KafkaPlugin 接口由宿主持有，kafka-0.10.jar 和 kafka-3.5.jar 各自提供不同实现，但宿主代码无需感知版本差异。
