无法通过修改字节码动态向密封类的permits列表追加未许可类，因JVM在类加载时强制校验PermittedSubclasses属性，该验证嵌入字节码且不可绕过；可行替代方案是用接口配合工厂或注册表模拟开放继承。
无法通过修改字节码动态向密封类（sealed class）的 permits 列表中追加未许可的运行期类。
密封类的 permits 列表在编译期静态确定
Java 的密封类机制由 JVM 在类加载阶段强制校验：permits 子句所声明的直接子类必须在编译时全部明确列出，且这些类必须与密封类在同一个模块（或同一包，若未使用模块系统）中。JVM 在加载密封类时会验证其所有 permitted 子类是否真实存在、是否被显式允许、是否满足继承约束（如 final、sealed 或 non-sealed）。该验证是类文件结构的一部分，嵌入在 PermittedSubclasses 属性中（自 Java 15 预览、Java 17 正式引入），属于不可绕过的核心语义检查。
字节码修改无法绕过 JVM 的密封性验证
即使你使用工具（如 ASM、Byte Buddy 或 Javassist）在类加载前或运行时修改密封类的字节码，向其 PermittedSubclasses 属性中添加新的类符号：
- JVM 仍会在链接（linking）阶段（具体为验证阶段 verification）检查每个被声明为 permitted 的类是否真实可访问、是否满足修饰符要求；
- 若新增的类在编译时尚未存在、未被声明、或其自身不满足
final/sealed/non-sealed要求，JVM 将抛出java.lang.IncompatibleClassChangeError或VerifyError； - 即使绕过验证（如使用非标准 JVM 或禁用验证的调试模式），后续实例化、反射、模式匹配等操作仍会因违反语言规范而失败或产生未定义行为。
运行期“扩展”密封类关系的可行替代方案
若目标是实现类似“动态允许新子类”的效果，应放弃修改密封类本身，转而采用设计层面的替代方式：
-
用接口 + 工厂/注册表模拟开放继承：定义一个公共接口，所有合法类型（包括运行期生成类）实现它，并通过服务注册、SPI 或 Map
, Handler> 统一管理； -
使用 non-sealed 中间层：将密封类设为
non-sealed的抽象基类（即放弃密封性），再通过运行时策略（如构造器检查、工厂方法、注解标记）控制合法子类； -
代码生成 + 编译期集成：在构建阶段（如 Annotation Processing 或 Gradle 插件）生成新子类并更新密封类的
permits列表，确保整个体系仍通过编译和 JVM 校验。
结论：密封性是语言级契约，不可运行期突破
Java 密封类的设计目标正是在编译期和加载期杜绝未授权子类的出现，这是类型安全与 API 可控性的基础保障。任何试图在运行期通过字节码注入“欺骗”JVM 的做法，都违背该特性的根本意图，且在标准 JVM 上必然失败。如需灵活性，请重构设计，而非对抗语言约束。
