在Java密封类体系中，non-sealed并非可选修饰符，而是对继承策略的显式契约声明——它明确告知编译器与开发者：此分支主动放弃密封约束，向未知子类开放继承，从而在类型安全与扩展性之间实现可控平衡。
在java密封类体系中，`non-sealed`并非可选修饰符，而是对继承策略的**显式契约声明**——它明确告知编译器与开发者：此分支主动放弃密封约束，向未知子类开放继承，从而在类型安全与扩展性之间实现可控平衡。
Java自17版本正式引入密封类（Sealed Classes），其核心目标是在编译期精确掌控类型层次结构。与传统final或包私有类的“全有或全无”限制不同，密封类提供了一种分层、可配置的继承治理机制。但这一机制的关键前提在于：所有直接子类必须显式声明其继承策略——即必须使用final、sealed或non-sealed三者之一进行修饰。
这并非语法冗余，而是设计哲学的体现：密封性不是默认状态的“例外”，而是一种需主动延续或主动解除的责任链。JEP 360明确指出：“密封类发起（initiates）一种封装约束，而每个许可子类都必须声明如何延续这一约束。” 换言之，permits列出的类不是“被允许存在”，而是“被委托决策”——它们共同构成整个类型家族的治理协议。
来看一个典型场景：
public abstract sealed class Shape permits Circle, Rectangle, Square { }
final class Circle extends Shape { /* 不可扩展 */ }
sealed class Rectangle extends Shape permits TransparentRectangle, FilledRectangle {
/* 继续密封，仅允许两个已知子类 */
}
final class TransparentRectangle extends Rectangle { }
final class FilledRectangle extends Rectangle { }
non-sealed class Square extends Shape {
/* 主动开放：允许任意第三方实现，如 UserDefinedSquare */
}若将Square写成 public class Square extends Shape { ... }（即省略non-sealed），编译器会直接报错：
立即学习“Java免费学习笔记（深入）”；
error: class Square must be declared either 'final', 'sealed', or 'non-sealed'
原因正在于此：Java拒绝隐式行为。不加修饰的普通类在密封语境下语义模糊——它既不表示“终结继承”（final），也不表示“继续受限扩展”（sealed），更不表示“开放扩展”（non-sealed）。这种模糊性违背了密封类“编译期可知全部子类型”的根本承诺。
因此，non-sealed的本质价值在于意图显性化：
- ✅ 对编译器：明确解除该分支的密封约束，允许后续任意class X extends Square合法通过编译；
- ✅ 对框架作者：在保持核心模型封闭（如Circle/Rectangle不可篡改）的同时，为特定扩展点（如Square）预留插件化接口；
- ✅ 对调用方：一眼识别出Square是官方认可的“开放扩展锚点”，而非设计疏漏；其子类虽不可被编译器枚举，但语义上属于受控开放。
⚠️ 注意事项：
- non-sealed只能用于密封类的直接许可子类，不能用于间接后代；
- 一旦声明non-sealed，其子类不再受原密封类约束，可自由使用public/protected等任意访问修饰符；
- 过度使用non-sealed会削弱密封类的价值，应仅在明确需要第三方深度定制的场景（如框架SPI、领域特定扩展点）中谨慎启用；
- 与sealed和final一样，non-sealed是Java语言级关键字，需JDK 17+支持，且要求模块化环境或同一包内定义。
总结而言，non-sealed不是“绕过限制”的捷径，而是密封体系中一种有边界的授权机制。它让开发者在“绝对封闭”与“完全开放”之间，精准选择第三条路：以声明式语法，赋予特定分支可信赖的扩展自由——这才是现代Java类型安全演进的真正深意。
