密封类详解：Java新特性限制继承体系

Java密封类作为一项关键的继承控制新特性，通过permits子句显式限定可扩展的子类范围，并强制子类以final、sealed或non-sealed明确响应，从而在编译期精准管控类型演化边界；它不仅支持与record、enum自然协同，还赋能switch表达式实现安全穷尽匹配，而non-sealed的巧妙引入更让开发者能在严格封装与灵活扩展之间动态权衡——真正考验的不是语法细节，而是对领域模型演进节奏的深刻理解与主动设计。

密封类怎么声明才合法

Java 的 sealed 类必须显式列出所有允许的子类，且这些子类必须用 permits 子句声明，或在同一个编译单元中直接定义并用 non-sealed / final / sealed 明确响应。

常见错误现象：error: sealed type must have at least one permitted subtype 或子类编译失败提示 “not allowed to extend sealed class”。

• permits 列表里的类名必须是**已存在或同文件定义**的类，不能是未声明的引用
• 被许可的子类必须在 permits 中**全名拼写一致**（含包名），如果子类在其他文件，需确保它和父类在相同模块且模块描述符中开放了该包
• 子类不能是匿名类、本地类，也不能是泛型类型参数化后的具体类（如 Node）
• 如果子类在另一个文件，它必须用 final、sealed 或 non-sealed 三者之一修饰——漏掉会报错

sealed + non-sealed 组合的实际意义

用 non-sealed 是为了“在密封链中开一个口子”，让某个子类可以继续被任意继承，而其他分支仍受控。这不是妥协，而是分层控制的设计选择。

使用场景：比如你定义了 Expression 密封类，允许 Literal、BinaryOp、Variable；其中 BinaryOp 本身结构稳定，你希望它也密封；但 Variable 可能需要用户扩展为 EnvVariable、ConfigVariable 等，这时就把它声明为 non-sealed。

• non-sealed 类本身**不自动继承父类的密封性**，它只是“解除父类对它的继承限制”，后续继承关系由它自己决定
• 如果误把本该 non-sealed 的子类写成 final，会导致用户无法扩展，但编译器不会警告——这是设计意图问题，不是语法错误
• 模块化项目中，non-sealed 类若在导出包里，外部模块才能继承它；没导出=实际仍不可继承

switch 表达式匹配 sealed 类时的 exhaustiveness 检查

Java 编译器在 switch 中对密封类做穷尽性检查（exhaustiveness），前提是 switch 的类型是密封类，且所有 permitted 子类都出现在 case 分支中（或有 default），否则报错：the switch expression does not cover all possible values。

性能影响很小，这是编译期检查，不增加运行时开销；但能提前暴露漏处理的子类，尤其在新增子类后忘记更新 switch 逻辑时。

• case 必须是具体子类名，不能用通配或模式变量（如 case Expression e: 不触发穷尽检查，除非启用 preview 的模式匹配特性）
• 如果子类是 non-sealed，则不能只列它——因为它的子类数量不可知，编译器拒绝认定“穷尽”，此时必须加 default
• IDE 可能提示“add missing cases”，但别盲目点；先确认是否真要覆盖全部，还是有意用 default 处理未知扩展

和 record、enum、interface 混用的边界情况

密封类可以是 record（从 Java 15+ 支持），也可以是 enum（enum 本身就是隐式 sealed），但不能直接是 interface——接口不能用 sealed 修饰，不过可以用 sealed 类实现接口，再让子类继承该类。

容易踩的坑在于混淆“密封的是谁”：比如你写了 sealed interface Shape permits Circle, Rect，这会直接编译失败，因为 sealed 不能修饰 interface。

• record 做密封父类时，其组件字段自动 final，子类不能重写 accessor，但可以定义自己的字段和方法
• enum 实现密封语义是天然的，无需加 sealed 关键字；但它不能作为 permits 列表中的成员（enum 是具体值，不是可继承的类）
• 如果密封类实现了某个 interface，子类不必重复 implements——继承即继承契约，但子类若想额外实现别的 interface，可以自由添加

真正难的不是语法，是判断哪些类该密封、哪些分支该开放、哪些 case 该用 default 而不是硬列全——这取决于你是否真的掌控了领域模型的演化节奏。漏掉一个 non-sealed 或多写一个 permits 条目，系统边界就悄悄变了。

好了，本文到此结束，带大家了解了《密封类详解：Java新特性限制继承体系》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多文章知识！