non-sealed并非冗余语法，而是密封继承体系中有意识、可审计、可追溯的开放声明——它明确打破密封链的某一分支，使该子类成为合法扩展入口，既保障核心类型安全，又为框架预留可控演进空间。
`non-sealed`并非冗余语法，而是密封继承体系中**有意识、可审计、可追溯的开放声明**——它明确打破密封链的某一分支，使该子类成为合法扩展入口，既保障核心类型安全，又为框架预留可控演进空间。
在Java 17正式引入的密封类（Sealed Classes）机制中，sealed关键字本身仅完成“起点封控”：它声明一个类的直接继承者集合是穷尽且可知的。但真正的设计精妙之处，在于对继承链后续行为的分层管控能力——而这正是final、sealed与non-sealed三者协同的核心意义。
为什么必须显式声明 non-sealed？
关键在于 “默认封闭”原则。Java密封类的设计哲学是：一切继承行为必须显式声明意图，禁止隐式开放。若允许 public class Square extends Shape { ... } 这样无修饰符的写法，则编译器无法区分这是开发者疏忽遗漏修饰符，还是有意开放——这将彻底瓦解密封机制的确定性保障。
因此，JLS明确规定：每个被permits列出的直接子类，必须且只能使用以下三者之一作为修饰符：
- final：终结该分支，不可继承（如 Circle）；
- sealed：延续密封策略，需配合自己的permits（如 Rectangle 允许 TransparentRectangle 和 FilledRectangle）；
- non-sealed：主动、明确、可审查地解除密封约束，允许任意外部类继承（如 Square）。
✅ 正确示例（结构清晰、意图明确）：
立即学习“Java免费学习笔记（深入）”；
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 { / 显式开放：任何模块/包均可继承 / }
> ❌ 错误示例（编译失败）：
```java
class Square extends Shape { } // 编译错误！缺少 final/sealed/non-sealed 修饰符non-sealed 的典型应用场景
| 场景 | 说明 | 示例 |
|---|---|---|
| 框架扩展点 | 核心模型密封，但为特定子类留出插件化接口 | Result 密封，Pending 声明为 non-sealed，供业务模块实现 TimedPending、RetryablePending 等 |
| 领域模型演进 | 当前版本固定基础形状，但允许未来自定义复合图形 | Shape 密封，CustomShape 为 non-sealed，第三方库可继承并添加 SVGShape、AnimatedShape |
| 测试友好设计 | 生产代码严格密封，测试时需 Mock 子类 | non-sealed 子类便于在测试包中创建轻量模拟实现 |
注意事项与最佳实践
- ? 模块可见性仍受约束：non-sealed 仅解除继承限制，不改变访问权限。若父类或子类为包私有，外部包仍无法继承；
- ⚠️ 类型安全性权衡：开放分支会削弱模式匹配（switch）的穷尽性检查——编译器不再能保证 Shape 的所有子类已知，需配合 default 分支或 sealed 接口增强校验；
- ? 语义即契约：non-sealed 是一种设计契约声明，应辅以 Javadoc 说明开放理由（如 @implSpec This class is non-sealed to support domain-specific extensions）；
- ? 与 sealed interface 协同：接口也可密封，non-sealed 类可实现密封接口，形成“类型协议封闭 + 实现开放”的混合模型。
综上，non-sealed 不是妥协，而是精密设计的杠杆：它让开发者在“完全封闭”与“完全开放”之间，获得可验证、可维护、可演进的第三条路径——这正是现代Java类型系统走向成熟的关键一步。
