Java 模式匹配 switch 处理层级类型的穷尽性

Java 模式匹配 switch 的“穷尽性”不是看代码里写了多少个 case，而是看这些标签能否覆盖 selector 的全部可能值。对于 sealed 接口或类，编译器可以读取 permits 中的直接子类型；这些子类型全部被无保护的类型模式覆盖时，switch 表达式可以不写 default。但 null、泛型层级和分离编译会改变判断边界，不能只凭“子类列全了”就认为运行时绝对安全。

实用判断顺序是：先确认 selector 的静态类型，再列出它允许的直接类型，最后单独决定 null 和未来层级变化由谁处理。显式列出已知子类型适合保持编译期提醒，default 更适合有意接受未知类型的兼容分支。

先把 sealed 层级变成覆盖集合

下面的例子把支付方式限制在三个直接实现类中。Cash、Card、Voucher 都是 Payment 的允许实现，因此 selector 的非空值可以按这三个类型分组：

sealed interface Payment permits Cash, Card, Voucher {}
record Cash(int cents) implements Payment {}
record Card(String token) implements Payment {}
record Voucher(String code) implements Payment {}

static String label(Payment payment) {
    return switch (payment) {
        // 三个无保护类型模式覆盖 Payment 的已知直接子类型
        case Cash cash -> "现金：" + cash.cents();
        case Card card -> "银行卡：" + card.token();
        case Voucher voucher -> "代金券：" + voucher.code();
    };
}

这里的关键不是 record，而是 Payment 的封闭层级。三个 case 的类型集合覆盖了 selector 的静态类型，所以表达式可以通过编译。若漏掉一个直接子类型，编译器会把它视为未覆盖值；这比普通语句静默跳过分支更容易在改动时暴露问题。

增强型 switch 的穷尽性要看标签形态

Java 21 之后，使用类型模式或 null 标签的增强型 switch 语句也要求穷尽；switch 表达式一直要求穷尽。普通常量 switch 语句则不一定需要覆盖所有值。还要留意模式支配关系：如果先写了一个能匹配全部值的模式，后面的更具体 case 就已经没有意义。

当层级不是 sealed，或者 selector 的声明类型比实际对象更宽时，最稳妥的兜底写法是保留 default：

static String describe(Object value) {
    return switch (value) {
        // 具体类型先处理，default 承接未列出的 Object
        case String text -> "文本：" + text;
        case Integer number -> "整数：" + number;
        default -> "其他类型";
    };
}

default 会让覆盖完整，但也会降低新增子类型时的编译提醒。对于业务状态、协议消息这类希望新增类型必须显式处理的场景，优先使用 sealed 加完整 case；对于插件、跨版本数据或确实允许未知值的边界，才把 default 作为有意的兼容策略。

null、嵌套类型与 MatchException 的边界

类型模式通常不会匹配 null。即使三个子类型已经覆盖了所有非空 Payment，传入 null 仍需要明确策略。若空值有业务含义，可以直接加入标签：

static String labelNullable(Payment payment) {
    return switch (payment) {
        // null 是独立边界，不属于任意一个类型模式
        case null -> "未选择支付方式";
        case Cash cash -> "现金";
        case Card card -> "银行卡";
        case Voucher voucher -> "代金券";
    };
}

另一种方案是在进入方法时建立非空约束，再让后续代码使用非空对象；不要用无意义的 default 掩盖空值来源。嵌套 record 也有类似问题：外层 record 的组件类型可能已经被 sealed 子类覆盖，但组件本身为 null 时，嵌套模式未必真的能匹配。

还要考虑分离编译。若 sealed 层级后来新增了许可子类型，而包含穷尽 switch 的类没有重新编译，运行时可能遇到没有对应标签的值并抛出 MatchException。这不是把 default 随便加上就能替代的发布策略：变更层级后应重新编译使用该层级的类，并把相关模块一起回归。

落地前的四项检查

相关问题

为什么 sealed 子类型都写了还提示不穷尽？ 先检查 selector 是否是泛型实例、case 是否带 guard，以及是否存在未覆盖的 null；泛型参数可能让某个 permits 分支在当前参数化下不可达，也可能暴露出新的可达组合。

default 和补齐所有子类型哪个更好？ 需要新增子类型时尽早暴露编译错误，就补齐显式 case；必须兼容未知实现时才使用 default，并在分支中留下可观测的降级处理。

参考：Java SE 26 JLS 第 14 章、Oracle Pattern Matching with switch、MatchException API。