ClassCastException主因是同一类被不同ClassLoader加载，导致JVM视为不同类型；推荐方案为父加载器统一提供共享类，次选JSON/Map桥接，慎用反射绕过。
Java 插件开发中遇到 ClassCastException，绝大多数是因为同一个类被不同类加载器（ClassLoader）加载了多次，导致 JVM 认为它们是“不同”的类型——即使类名、包名、字节码完全一致，只要加载器不同，就无法相互强转。
理解根本原因：类加载器隔离是关键
插件系统（如 IntelliJ、Eclipse、自研 SPI 框架）通常为每个插件分配独立的 ClassLoader（如 URLClassLoader 或自定义子加载器），以实现类隔离。但这也带来一个问题：插件里用到的某个类（比如 com.example.Config），如果主程序也定义或加载过一次，就会出现两个“同名但不兼容”的类实例。
- 主程序通过 AppClassLoader 加载
Config - 插件通过 PluginClassLoader 加载另一个
Config - 当插件把
Config实例传给主程序方法时，JVM 拒绝转型：ClassCastException
方案一：统一由父加载器提供共享类型（推荐）
让插件和宿主共用同一份类定义——把需要跨边界传递的类（接口/DTO/常量类）放到宿主的 classpath 中，确保只由父加载器（如 AppClassLoader）加载。
- 插件 jar 中不要打包这些共享类（
maven-shade-plugin排除，或providedscope） - 宿主启动时提前将这些类暴露给插件加载器（例如重写
URLClassLoader的loadClass，优先委派给父加载器） - 定义清晰的“契约类”：只用接口或简单 POJO（无依赖、无静态初始化块），避免意外触发子加载器加载其他类
方案二：用字符串/Map/JSON 做数据桥接（绕过类型）
如果无法控制类加载策略（比如第三方插件平台不允许修改宿主类路径），就放弃直接传对象，改用“无类型”载体：
立即学习“Java免费学习笔记（深入）”；
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 插件把配置对象序列化成 JSON 字符串，宿主反序列化为自己的实例
- 用
Map<string object></string>传递键值对（类似 Spring Boot 的@ConfigurationProperties绑定逻辑） - 定义标准协议字段（如
"timeout": 5000, "enabled": true），双方按约定解析
这种方式牺牲了编译期类型检查，但彻底规避了类加载冲突。
方案三：反射 + 类加载器显式控制（慎用）
仅在极少数必须传对象且无法改架构时考虑。核心思路是：让接收方用“发送方的类加载器”去加载目标类，再通过反射构造/赋值。
- 插件拿到自己加载的
Config.class，连同实例一起传给宿主（如封装进PluginObjectWrapper） - 宿主通过
wrapper.getClassLoader().loadClass("com.example.Config")获取对应 Class - 用反射读取字段、调用 getter，或借助
Objenesis+sun.misc.Unsafe（不推荐）绕过构造器
该方式耦合高、可维护性差，容易引发 NoClassDefFoundError 或安全限制问题，仅作兜底手段。
不复杂但容易忽略：真正要解决的不是“怎么 catch 异常”，而是“不让它发生”。从设计阶段就划分好类归属边界，比事后处理异常更可靠。
