java密封接口自17引入、20优化，通过public sealed interface x permits a,b,c声明，配合final/sealed/non-sealed修饰符控制实现类继承边界，并与switch模式匹配协同实现编译期穷举验证。
Java 密封接口（Sealed Interfaces）是自 Java 17 正式引入、并在 Java 20 进一步优化的关键特性，它让开发者能在编译期精确控制哪些类可以实现某个接口，从而把“多态实现范围”从“完全开放”转变为“受控演进”。这不是简单的语法糖，而是类型安全与架构可控性的底层支撑。
密封接口的核心写法与约束逻辑
密封接口不是加个 sealed 就完事——它是一套协同生效的声明契约：
- 接口必须用
public sealed interface X permits A, B, C显式声明 -
permits后列出的所有实现类，必须与该接口位于同一模块（或同一包，若未启用模块系统） - 每个被允许的实现类，必须明确使用以下三者之一修饰：
-
final：彻底封闭，不可再被继承（适合叶节点实现） -
sealed：可继续限制其子类（适合中间抽象层） -
non-sealed：主动解除密封限制，允许任意扩展（Java 20 引入的关键灵活性）
-
例如：
public sealed interface Command permits LoginCommand, LogoutCommand, CustomCommand { }
final class LoginCommand implements Command { /* 不可再扩展 */ }
final class LogoutCommand implements Command { /* 不可再扩展 */ }
non-sealed class CustomCommand implements Command { /* 允许第三方继承 */ }
这个结构意味着：你既锁定了核心命令集（Login/Logout），又为插件或定制场景留出了合法出口（CustomCommand 可被外部模块继承）。
实现类的演进边界由修饰符决定
每个 permits 列表中的类，其修饰符直接定义了它在继承链中的“开放程度”：
-
final类：终止演进。它本身是完整实现，不接受任何子类。适用于确定不变的行为单元。 -
sealed类：延续控制。它可声明自己的permits子类，形成多层密封树。例如sealed class Payment implements Command permits CreditPayment, DebitPayment。 -
non-sealed类：移交控制权。它不破坏整体密封性，但把“谁可以继承我”的决策权交给下游——这正是框架支持第三方扩展的合规路径。
关键点在于：non-sealed 不等于“破坏密封”，而是把密封策略下放一级。整个接口仍保持封闭可穷举，只是某一支允许生长。
配合模式匹配提升多态安全性
密封接口真正的威力，在于与 switch 表达式 + 模式匹配协同工作：
double execute(Command cmd) {
return switch (cmd) {
case LoginCommand c -> c.authenticate();
case LogoutCommand c -> c.clearSession();
case CustomCommand c -> c.handle(); // 编译器知道只有这三种可能
};
}
编译器能验证该 switch 已覆盖所有 permits 列出的实现类——无需 default 分支，也不会漏掉新增类型。一旦有人试图新增 AdminCommand implements Command，编译直接报错，而不是等到运行时才发现类型缺失。
场景化设计建议：何时该用、怎么分层
领域模型固定枚举型行为（如状态机、表达式节点、协议消息体）
→ 主接口sealed，所有实现用final，确保业务语义封闭。框架核心 API + 插件扩展点
→ 主接口sealed，内置实现用final或sealed，预留一个non-sealed实现类供用户继承。需要多级抽象的 DSL 层次（如解析器 AST 节点）
→ 接口sealed；抽象基类（如BinaryExpression）用sealed并再permits具体运算符；叶子节点用final。
不复杂但容易忽略：所有 permits 类必须显式写出全限定名（不能靠 import 简写），且必须在同一个编译单元可见——跨模块需导出并 requires，否则编译失败。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
