Java switch 模式匹配怎么处理密封类型的穷尽性

我第一次把一串 if (result instanceof ...) 改成 Java 21 的模式匹配 switch 时，真正有价值的并不是少写了几行判断，而是编译器开始替我盯着领域模型：只要密封层级新增一种结果，旧的 switch 就会立刻暴露缺口。

要得到这种保护，关键不是机械地补一个 default，而是让选择器类型保持密封，并让无守卫的 case 覆盖所有可达的允许子类型。本文用一个订单处理结果模型，把 Java switch 模式匹配的穷尽性规则讲清楚。

官方依据：JEP 441：Pattern Matching for switch；Java SE 21 JLS 14.11.1.1

模式命名：把穷尽性当成模型契约

这里的模式可以叫“密封分派”：根类型用 sealed 限定实现集合，switch 再用类型模式处理每一种允许结果。两者配合后，分支完整性不再依赖代码评审者逐个比对，而成为编译器可以证明的性质。

JLS 对密封类型的核心规则是：如果选择器类型对应一个抽象密封类或密封接口，那么所有与该选择器类型相容的允许直接子类、子接口都被覆盖时，switch 就是穷尽的。这个判断看的是类型覆盖，不是运行时恰好出现过哪些对象。

适用压力：当领域结果会演进时最有价值

支付、订单、任务调度、协议响应这类模型通常只有少数合法状态，却会随着业务扩展新增状态。传统的 if/else 可以工作，但无法保证每个调用点都同步更新；一个兜底分支还可能把新状态悄悄归入“其他”。

密封分派更适合下面的压力：结果种类是有限集合；每种结果需要不同处理；新增结果必须推动所有关键分派点一起修改。它不适合开放插件体系，因为插件实现本来就不应由根模块穷举。

典型实现：列出所有允许子类型，不写 default

先把领域结果声明成密封接口。三个 record 都是隐式 final，因此这棵类型树的叶子范围是确定的。

import java.time.Duration;

sealed interface PaymentResult
        permits Success, Rejected, Pending {
}

record Success(String paymentId) implements PaymentResult {
}

record Rejected(String reason) implements PaymentResult {
}

record Pending(Duration retryAfter) implements PaymentResult {
}

接着让 switch 表达式逐一覆盖三个允许类型：

static String describe(PaymentResult result) {
    return switch (result) {
        // 每个无守卫类型模式都贡献一部分类型覆盖。
        case Success s -> "支付成功：" + s.paymentId();
        case Rejected r -> "支付拒绝：" + r.reason();
        case Pending p -> "稍后重试：" + p.retryAfter();
    };
}

这里没有 default 仍能通过编译，因为 Success、Rejected 和 Pending 覆盖了 PaymentResult 的全部允许直接实现。switch 表达式本身必须穷尽；Java 21 中使用模式或 null 标签的增强型 switch 语句也必须穷尽。

反例：default 看似保险，实际会遮住模型变化

很多人会下意识补一条 default -> "未知结果"。这能满足语法上的穷尽要求，却也让编译器失去提醒机会。假设后来新增 ManualReview，旧代码仍然能编译，新状态只会在运行时落进模糊兜底。

static String describe(PaymentResult result) {
    return switch (result) {
        case Success s -> "支付成功";
        case Rejected r -> "支付拒绝";
        case Pending p -> "等待确认";
        // 这个兜底会吞掉未来新增子类型带来的编译缺口。
        default -> "未知结果";
    };
}

如果业务要求每一种结果都有明确语义，更稳妥的做法是省略 default。新增允许子类型后，所有依赖完整分派的 switch 都会变成待修复的编译错误，影响范围因此直接可见。

后果一：覆盖直接分支，还是枚举所有叶子

编译器沿着允许直接子类型判断覆盖。若某个允许子类型本身还是 sealed，你可以用一个针对该中间类型的无守卫模式覆盖整条分支，也可以继续列出它的叶子类型。前者稳定、分支少；后者语义更细，但层级变化时需要修改更多位置。

sealed interface OrderState permits Completed, Failed, Active {
}
record Completed() implements OrderState {
}
record Failed(String reason) implements OrderState {
}
sealed interface Active extends OrderState permits Waiting, Running {
}
record Waiting() implements Active {
}
record Running() implements Active {
}

static String group(OrderState state) {
    return switch (state) {
        case Completed c -> "已完成";
        case Failed f -> "失败";
        // 一个无守卫的 Active 模式覆盖整个活动分支。
        case Active a -> "进行中";
    };
}

但如果直接允许的是 non-sealed 类型，就无法再枚举该分支未来所有实现。此时用这个 non-sealed 中间类型本身作为 case，才能覆盖整条开放分支。

后果二：有守卫的 case 不能随便承担全覆盖

穷尽性统计依赖无守卫模式，或者守卫恒为 true 的模式。业务条件可能为假的守卫只覆盖部分值，不能单独代表整个类型。下面的代码仍缺少“金额不大于零的成功结果”：

static String audit(PaymentResult result) {
    return switch (result) {
        // 守卫只覆盖 Success 的一部分值，不能代表全部 Success。
        case Success s when !s.paymentId().isBlank() -> "有效成功结果";
        case Rejected r -> "拒绝";
        case Pending p -> "等待";
        // 补上未满足守卫条件的 Success，整个类型才被覆盖。
        case Success s -> "成功结果缺少编号";
    };
}

模式还要遵守支配关系：宽泛模式必须放在更具体模式之后，否则后面的分支永远无法命中，编译器会拒绝这种代码。把 case Object o 放在 case String s 前面就是典型错误。

null 是另一条轴，不会被 sealed 自动覆盖

密封层级描述的是非空对象可能属于哪些类型，并不自动表示选择器可以接收 null。若没有 case null，选择器值为 null 时会抛出 NullPointerException。这通常是合理的失败方式，因为领域结果本就不应为空。

只有当 null 在业务上确实有独立含义时，才显式加入：

static String describeNullable(PaymentResult result) {
    return switch (result) {
        // 只有业务明确允许缺失结果时才接纳 null。
        case null -> "尚未产生支付结果";
        case Success s -> "支付成功";
        case Rejected r -> "支付拒绝";
        case Pending p -> "等待确认";
    };
}

不要为了“看起来更完整”机械地加 case null。如果参数契约是不允许空值，让空值快速失败反而更清晰。

泛型 sealed 层级会排除不可能出现的分支

JLS 还会结合选择器的类型参数判断可达性。某个允许子类型如果只能实现 Result，那么选择器是 Result 时，这个子类型不可能出现，编译器无需强迫你写一条不可达分支。这是“覆盖选择器类型”，不是机械点名 permits 列表中的每个名字。

独立编译与运行期版本漂移仍需留意

源码一起编译时，省略分支会直接报错。但库和业务模块可能分别编译：业务模块按旧版密封层级编译，运行时却加载了新增允许子类型的新版库。Java 21 会为源码层面穷尽、但没有显式全匹配标签的增强型 switch 保留运行时防线；若没有任何标签匹配，将抛出 MatchException。

这不是建议用异常代替重新编译。升级包含密封层级的依赖时，仍应让下游模块重新编译并执行测试，才能把新分支恢复成编译期可见的问题。

判断清单

常见问题

sealed 类型的 switch 一定不能写 default 吗？

语法上可以写。只是当你的目标是让模型新增分支触发编译提醒时，default 会削弱这项收益。边界适配层若确实需要统一兜底，可以写，但应明确接受这个取舍。

为什么只覆盖 permits 里的直接类型就够了？

穷尽性规则以允许直接子类型为边界。若某个直接子类型本身代表整条分支，对它使用无守卫类型模式，就已经覆盖该分支的所有实例；只有需要区分叶子语义时才继续向下拆。

switch 语句和 switch 表达式的要求一样吗？

switch 表达式必须穷尽。Java 21 的增强型 switch 语句——例如包含类型模式或 case null 的语句——也必须穷尽；传统的非增强型 switch 语句为兼容性仍可不穷尽。

我现在审查这类代码时，会先看类型树，再看 case：根类型负责限定世界，模式分支负责解释世界，而省略 default 让世界变化时编译器主动敲门。这样使用密封类型，穷尽性才不只是语法要求，而是一条可以持续维护的架构契约。