要真正利用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 检查。编译器无法分析这种运行时类型链是否完备。
正确做法是使用 switch 表达式 + 类型模式匹配：
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
立即学习“Java免费学习笔记（深入）”；
- 每个
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 中处理它的子类（此时已超出编译器可知范围）
