要真正利用java密封类的穷尽性检查，必须同时满足：密封类用sealed+permits显式声明全部直接子类；各子类为final/sealed/non-sealed且non-sealed需谨慎；switch操作数类型必须是密封类本身并用类型模式匹配，不写default。

要在 Java 中真正利用密封类的 exhaustive 检查保障业务逻辑覆盖所有子类，关键不是“用了 sealed”，而是让编译器能静态确认你没漏掉任何分支——这需要语法、结构和用法三者协同。

必须满足的三个硬性前提

编译器只在严格满足以下条件时才启用穷尽性检查：

• 密封类（或接口）必须用 sealed 声明，并通过 permits 显式列出全部直接子类（如 permits Circle, Rectangle, Triangle）
• 每个 permits 列出的子类必须是 final、sealed 或 non-sealed；若选 non-sealed，它后续的子类就脱离密封体系，无法被编译器追踪
• switch 表达式操作数的类型必须是该密封类本身（例如 switch (shape) { ... } 中 shape 类型是 Shape），不能是其父类（如 Object）、接口（如 Serializable）或泛型擦除后的类型

用 switch 表达式代替 if-is 链

这是最容易踩坑的地方：用多个 if (x instanceof Circle) 判断会完全绕过 exhaustive 检查。编译器无法分析这种运行时类型链是否完备。

Java Maven Common

Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。

下载

正确做法是使用 switch 表达式 + 类型模式匹配：

• 每个 case 直接写子类类型，如 case Circle c -> c.radius * Math.PI * c.radius
• 不写 default 分支；如果遗漏任一 permits 子类，编译直接报错：the switch expression does not cover all possible inputs
• 返回值类型需统一（如都返回 double），避免靠 default 补逻辑漏洞

配合记录类建模，减少手动维护成本

密封接口 + 记录类是表达封闭数据结构的推荐组合，既保证不可变性，又天然适配 exhaustive：

• 声明 public sealed interface Command permits Login, Logout, Transfer {}
• 实现为 public record Login(String user) implements Command {} 等
• 处理时直接 switch (cmd) { case Login(var u) -> ...; case Logout() -> ...; }，解构与穷尽一步到位
• 新增命令只需加一个 record 并更新 permits，所有已有 switch 处立刻编译失败，强制补全

警惕破坏穷尽性的常见操作

以下做法会让 exhaustive 形同虚设：

• 在 switch 外部用 getClass()、instanceof 或 toString() 做类型判断
• 把密封类对象先转成 Object 或其他宽泛类型再传入 switch
• 子类定义在另一个模块但未在 module-info.java 中显式 opens 或 requires 密封类所在包
• 误用 non-sealed 允许子类进一步扩展，却没在 switch 中处理它的子类（此时已超出编译器可知范围）

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南