Java sealed 类型配合 switch 完成穷尽分支

当一个业务对象只有几种合法形态时，sealed 类型配合模式匹配 switch，可以把“分支是否覆盖完整”交给 Java 编译器检查。关键做法是：在 permits 中声明直接子类型，让这些子类型保持 final 或使用 record，然后在 switch 中逐个写出类型模式。覆盖全部允许类型后，switch 表达式可以不写 default。

这套写法适合状态、命令、事件等封闭模型。它解决的是编译期穷尽检查，不会自动替你处理 null，也不能替代对类型层次变更后的完整重新编译。

官方资料：https://docs.oracle.com/en/java/javase/26/language/switch-expressions-statements.html

先用 sealed 和 permits 固定类型边界

sealed 接口限制直接实现者，permits 列出允许的直接子类型。下面的订单动作只有三种形态：创建、取消和改地址。每个 record 天然是不可再继承的，编译器可以据此知道层次没有隐藏的第四种直接实现。

sealed interface OrderAction
        permits CreateOrder, CancelOrder, ChangeAddress {
    // 封闭接口只描述允许出现的动作集合
}

record CreateOrder(String orderId) implements OrderAction {}
record CancelOrder(String orderId, String reason) implements OrderAction {}
record ChangeAddress(String orderId, String address) implements OrderAction {}

这里的边界是“直接子类型”。如果某个允许类型继续开放继承，或者把它声明为 non-sealed，编译器就不能只靠当前文件推断所有运行时类型，后面的 switch 通常需要 default。

让 switch 按具体类型完成穷尽分支

模式匹配 switch 可以直接绑定每个 record 的变量。因为选择器类型是封闭的 OrderAction，三个 case 已经覆盖全部允许类型，所以表达式不需要兜底 default。箭头语法也避免了传统 switch 的贯穿问题。

static String describe(OrderAction action) {
    return switch (action) {
        case CreateOrder create -> {
            // 绑定后的 create 只在当前分支有效
            yield "创建订单：" + create.orderId();
        }
        case CancelOrder cancel ->
                "取消订单：" + cancel.orderId() + "，原因：" + cancel.reason();
        case ChangeAddress change ->
                "修改地址：" + change.orderId() + " -> " + change.address();
    };
}

如果漏掉 ChangeAddress，编译器会报告 switch 没有覆盖所有可能输入。这个错误比线上遇到未知分支更早，而且新增一种允许动作时，所有依赖该层次的穷尽 switch 都会成为明确的迁移清单。

模式顺序和 null 是两个独立问题

类型模式仍然有覆盖关系。更宽的模式放在前面会支配更窄的模式，例如先写 case OrderAction a，后面的三个具体类型就永远到不了；应先写具体模式，再考虑更宽的模式。另一个容易混淆的点是 null：封闭类型只限制非空对象的类型集合，选择器为 null 时，未写 case null 仍可能抛出 NullPointerException。

static String safeDescribe(OrderAction action) {
    return switch (action) {
        case null -> {
            // null 不是 permits 中的子类型，需要单独决定策略
            yield "没有动作";
        }
        case CreateOrder create -> "创建：" + create.orderId();
        case CancelOrder cancel -> "取消：" + cancel.orderId();
        case ChangeAddress change -> "改址：" + change.orderId();
    };
}

如果业务上 null 代表调用方错误，也可以不接住它，让异常暴露出来；如果它来自可选输入，则显式写 case null 更容易把策略写在代码里。不要用一个无条件的宽类型模式来掩盖缺少的业务分支。

类型层次变化后要重新编译相关 switch

实际维护中，最重要的检查点不是“当前代码能不能编译”，而是“sealed 层次改动后，所有使用方是否一起重编译”。例如给 OrderAction 增加 RefundOrder 后，原来的穷尽 switch 就必须补上新分支。若拆分编译产物没有同步更新，Java 26 文档还特别说明了运行时可能出现 MatchException，因此发布流水线应把类型定义和使用方放在同一构建单元或同一回归编译中。

常见问题

sealed 接口一定要写 permits 吗？不一定。若省略，Java 可以从同一编译单元中推断直接子类型；但跨文件维护时显式写出 permits 更直观，也更适合作为团队边界文档。

为什么加了 default 后编译器不再提醒新增类型？因为 default 已经覆盖所有未匹配值，编译器没有必要把每个允许类型都当成必须出现的 case。若希望新增子类型时强制修改业务分支，保留无 default 的穷尽表达式。

record 不是必须的吗？不是。普通 final class 也可以作为允许子类型；record 只是让不可变数据载体和类型模式示例更紧凑。

总结来说，sealed 负责声明“哪些类型合法”，模式匹配 switch 负责声明“每种合法类型怎么处理”，编译器则负责在类型集合变化时提醒你补齐分支。把 null 策略和重新编译边界写清楚，这种组合就能成为可靠的状态分派结构。