不推荐 plugin extends extension，因破坏类加载隔离导致类型校验失败；应改用接口契约（如 iextension），由宿主类加载器统一加载接口，插件类加载器以宿主为 parent，确保类型一致性。
Java插件化中不推荐用 Plugin extends Extension 这种继承方式实现动态加载，它会直接破坏类加载隔离的安全边界，导致类型校验失败、ClassCastException 或 NoClassDefFoundError。真正可行且稳定的做法是基于接口契约，而非继承关系。
为什么不能让插件继承宿主的 Extension 类
Extension 通常是宿主定义的具体类（含字段、构造逻辑、静态初始化块等），一旦插件 JAR 中依赖并继承它，就要求该类必须在插件自己的类路径里——但插件运行时不应打包宿主类；若靠宿主类加载器提供，则因双亲委派机制，插件类加载器加载的子类与宿主加载的父类属于不同 ClassLoader 实例，JVM 认为它们是完全无关的类型，强转必然失败。
- 继承引入了编译期耦合和运行时类加载绑定，违背插件“松耦合、可卸载”本质
- Extension 若含静态字段或初始化代码，可能引发多份副本、状态污染或初始化冲突
- OSGi、PF4J 等成熟框架全部弃用继承模型，只接受 interface 实现
正确的类型契约：用接口替代 Extension
应将 Extension 抽象为纯接口（如 IExtension），不含默认方法、无静态成员、无构造器，仅声明行为契约。宿主发布独立的 api.jar，插件仅编译期依赖它，运行时不包含该 jar。
- 接口由宿主类加载器加载（确保所有插件看到的是同一份类型定义）
- 插件实现类由自定义 URLClassLoader 加载，但强制指定宿主类加载器为 parent
- 实例化后，用宿主加载的接口类型接收对象：
IExtension ext = (IExtension) pluginInstance;
动态加载时的关键类型校验步骤
避免 ClassCastException 的核心在于保证“接口类型”始终出自宿主类加载器，而非插件类加载器。
- 加载插件类前，先通过
Thread.currentThread().getContextClassLoader().loadClass("IExtension")确认接口已由宿主加载 - 创建插件类加载器时显式传入宿主类加载器：
new URLClassLoader(urls, hostClassLoader) - 加载实现类后，用
hostClassLoader.loadClass("IExtension")获取接口 Class，再调用asSubclass()或安全 cast - 禁止在插件中 import 并 new 出 Extension 实例——这会触发插件 loader 加载父类，彻底绕开校验
如果已有 Extension 类，如何平滑迁移
不必重写全部逻辑。可保留原有 Extension 作为内部基类，同时定义一个镜像接口 IExtension，让宿主所有扩展点面向该接口编程，并提供适配器工具类：
- 新增
ExtensionAdapter工具：接收插件实现的IExtension，内部委托给宿主 Extension 实例（若需复用逻辑） - 宿主侧所有插件注册、调度、生命周期管理全部基于
IExtension接口 - 老插件可逐步改写为实现接口；新插件一律不接触 Extension 类
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
