密封接口必须显式声明permits，否则编译不通过；permits后须跟同一模块中已存在且可访问的类或接口名，不可用字符串或通配符，且所有被允许类型需与接口同时编译。
密封接口必须显式声明 permits，否则编译不通过
Java 17+ 引入密封接口（sealed interface）后，permits 不是可选语法糖，而是强制约束机制。漏写、写错类名、或类不在同一编译单元，都会直接报错：error: sealed type must have permits clause 或 error: class X is not listed in the permits clause of Y。
实操建议：
-
permits后必须跟**已存在且可访问的类或接口名**，不能是字符串字面量，也不能用通配符 - 所有被允许的实现类必须与密封接口在**同一模块**（如果用了模块系统），且**源文件需同时参与编译**——分开 javac 编译常导致 “class not found” 类错误
- 如果子类是嵌套类（如
static final class Impl），它必须声明为final、sealed或non-sealed；仅final最常用，也最安全
permits 列表里写 final 类还是 sealed 类，取决于是否还要再扩展
密封接口本身只管“谁可以实现我”，不管“那些实现类自己能不能被继承”。所以 permits 后面列的每个类型，都得自己决定自己的密封性策略。
常见组合和含义：
立即学习“Java免费学习笔记（深入）”；
- 写
permits A, B，而A是final class A implements MyInterface→A不可再被继承，这是最常见、最推荐的做法 - 写
permits A, B，而A是sealed class A implements MyInterface permits A1, A2→A可被有限继承，但只允许A1和A2扩展它；这种嵌套密封适合分层建模（比如协议 + 具体消息类型） - 写
permits A，而A是non-sealed class A implements MyInterface→ 开放继承，等于放弃密封控制，慎用
错误现象：把 permits 当成“允许实例化”的白名单——其实它只限制**编译期的直接实现关系**，运行时反射仍可能绕过（但会触发 IllegalAccessException）。
密封接口不能和 extends 混用时忽略父接口的密封性
如果一个接口既 extends 了另一个接口，又声明为 sealed，那么它的 permits 列表只约束**直接实现者**，不继承父接口的许可范围。更关键的是：父接口如果是密封的，子接口也必须是密封的，且必须显式重申许可规则。
例如：
sealed interface Animal permits Dog, Cat non-sealed interface Pet extends Animal // ❌ 编译错误：Pet 继承了 sealed 接口，自己也必须是 sealed
正确写法：
sealed interface Animal permits Dog, Cat sealed interface Pet extends Animal permits Dog, Cat // ✅ 必须重复列出可实现类，或加新类
容易踩的坑：
- 以为
extends sealed interface就自动继承其permits—— 实际上 Java 不传递许可，每个密封类型都要独立声明 - 在模块化项目中，父接口和子接口分布在不同模块，而
permits类只在本模块定义 → 编译器看不到跨模块类，报错“not listed”
IDE 和构建工具对密封类型的支持还不完全一致
IntelliJ IDEA 2022.3+ 对密封接口有较好提示，但 Eclipse 和部分老版本 Maven 插件（如 maven-compiler-plugin sealed 和 permits，导致编译通过但运行时行为失控。
实操建议：
- 确保
pom.xml中明确指定<release>17</release>或<source>17</source>和<target>17</target> - Gradle 用户需设
java.toolchain.languageVersion = JavaLanguageVersion.of(17) - 检查 IDE 的 Project SDK 和 Language Level 是否真为 17+，光装 JDK 不够，IDE 内部编译器也要切过去
最隐蔽的问题：本地 IDE 能编译，CI 流水线却失败——大概率是 CI 使用的 Maven 或 JDK 版本没对齐，不是代码问题。
