非密封子类（non-sealed）在密封体系中扮演着开放和扩展的角色。它允许其他类在不破坏原有密封结构的前提下，继承并扩展该类的功能。这种设计在面向对象编程中提供了灵活性，使得系统可以在保持核心结构稳定的同时，支持更多的定制和扩展。

non-sealed 是 Java 密封类机制中一个精巧而常被误解的关键设计：它并非打破密封体系，而是在继承链的特定层级主动“开一个口”，使当前子类成为可被任意继承的开放节点，同时严格保留父类的 sealed 约束和 permits 列表的权威性；它支持灵活扩展（如 Polygon 开放继承，其子类 RegularPolygon 却可再度密封），与 final 逻辑互斥、语法敏感，且在模式匹配中不破坏穷尽性检查——真正实现了“可控的开放”，让稳定性与可扩展性在类型系统中和谐共存。

non-sealed 不是“取消密封”，而是“在密封链上开一个口”

很多人误以为 non-sealed 是对整个密封体系的否定，其实它只作用于**当前子类这一层**。父类仍是 sealed，子类仍必须出现在 permits 列表里；只是这个子类自己不再约束它的后代——它成了继承链上的“开放节点”。

编译器不会报错，但会严格检查：该类是否被列在父类的 permits 中、是否用了 final/sealed/non-sealed 三者之一修饰。漏掉修饰符或写错关键字，直接编译失败。

为什么不能用 final + non-sealed 组合？

non-sealed 的语义就是“允许被继承”，而 final 表示“禁止被继承”，二者逻辑冲突。JVM 规范明确禁止这种组合，编译时抛出类似 error: illegal combination of modifiers: final and non-sealed 的错误。

常见误操作包括：

• 复制粘贴其他子类代码后忘记改掉 final
• IDE 自动生成类声明时默认加了 final，没手动删
• 把 non-sealed 错写成 non sealed（空格）或 nonsealed（少横线），导致编译器识别为普通标识符

non-sealed 类内部还能用 sealed 吗？

可以，而且很常见。一个 non-sealed 子类完全有权定义自己的子类体系，并用 sealed + permits 控制下一层继承。例如：

public non-sealed class Polygon extends Shape { }
public sealed class RegularPolygon extends Polygon permits EquilateralTriangle, Square { }

这说明开放性是有边界的：Polygon 开放给任意继承，但 RegularPolygon 又重新收紧控制。这种嵌套控制正是密封机制的实用之处。

注意：此时 RegularPolygon 的 permits 列表里的类，仍需各自声明封闭性（final/sealed/non-sealed），否则编译不通过。

模式匹配时，non-sealed 分支会影响 exhaustiveness 检查吗？

不影响。Java 编译器做 switch 模式匹配的穷尽性检查时，只看密封父类直接允许的子类（即 permits 列表），不递归检查 non-sealed 子类的后代。

也就是说，只要 Circle、Rectangle、Polygon 都在 Shape 的 permits 里，且你覆盖了这三者，switch (shape) 就算穷尽——哪怕 Polygon 后面还有 20 个子类，编译器也不管。

这点容易被忽略：开发者常以为“既然 Polygon 能被无限继承，那模式匹配就永远不安全”，其实不然。安全边界就在第一层密封定义上。

今天带大家了解了的相关知识，希望对你有所帮助；关于文章的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~