Java sealed interface 配合 switch 覆盖类型分支的方法

Java 中，sealed interface 可以把一个接口的直接实现者固定在 permits 列表里。把这个封闭类型交给支持模式匹配的 switch 表达式后，编译器能够检查所有允许的类型是否都被覆盖。本文用一个支付事件例子说明具体写法：CardPaid、CashRefund 和 ManualReview 各自返回一个结果，不写多余的强制转换。

示例按 Java 21 或更高版本组织。sealed classes 在 Java 17 成为正式特性，pattern matching for switch 在 Java 21 成为正式特性；不要为了这段代码额外打开 preview 开关。

关键做法是：让 switch 的选择器类型就是 sealed interface，并为每个可达的 permitted 类型写一个类型模式。所有分支都覆盖后，可以省略 default；null 则要在进入 switch 前处理，或单独写 case null。

先把封闭的类型集合定义清楚

下面的模型把支付结果拆成三个互不混淆的事件。两个 record 适合承载固定字段，人工复核使用普通 final class，说明 sealed interface 约束的是直接实现者，而不是要求所有实现都必须是 record。

// 文件名：PaymentEventDemo.java；示例使用 Java 21 或更高版本
sealed interface PaymentEvent permits CardPaid, CashRefund, ManualReview {
    // sealed interface 只允许 permits 中列出的直接实现者
}

record CardPaid(String orderId, long cents) implements PaymentEvent {
    // cents 使用最小货币单位，避免在示例中引入浮点误差
}

record CashRefund(String orderId, long cents) implements PaymentEvent {
    // 退款事件也保留订单号，便于后续分支生成统一结果
}

final class ManualReview implements PaymentEvent {
    private final String orderId;

    ManualReview(String orderId) {
        // 构造函数保存需要人工处理的订单号
        this.orderId = orderId;
    }

    String orderId() {
        // 提供一个最小访问器，避免把字段暴露为 public
        return orderId;
    }
}

编译器现在知道 PaymentEvent 的直接实现者只有三个。若再写一个没有出现在 permits 中的类去实现它，错误会出现在类型声明处，而不是等到某个 switch 分支才暴露。

用 switch 表达式覆盖每一种类型

选择器的静态类型必须是 PaymentEvent，每个 case 使用一个类型模式。由于三个 permitted 类型都已经列出，switch 表达式不需要再加 default，返回值也会在编译期被要求保持一致。

static String describe(PaymentEvent event) {
    // null 不会匹配普通类型模式，先给出明确的业务结果
    if (event == null) {
        return "缺少支付事件";
    }

    return switch (event) {
        case CardPaid paid -> {
            // 类型模式已经完成转换，可以直接读取 record 组件
            yield "订单 " + paid.orderId() + " 已支付 " + paid.cents() + " 分";
        }
        case CashRefund refund -> {
            // 退款分支只处理 CashRefund，不把它当作通用 PaymentEvent
            yield "订单 " + refund.orderId() + " 已退款 " + refund.cents() + " 分";
        }
        case ManualReview review -> {
            // 普通 final class 也可以用类型模式参与完整覆盖
            yield "订单 " + review.orderId() + " 待人工处理";
        }
    };
}

public static void main(String[] args) {
    // 三个输入分别走三个 permitted 类型分支
    System.out.println(describe(new CardPaid("A-100", 2599)));
    System.out.println(describe(new CashRefund("A-101", 800)));
    System.out.println(describe(new ManualReview("A-102")));
}

这里的重点不是把 if/else 改成更短的语法，而是把“事件有哪些合法类型”交给类型系统维护。以后新增一个 permitted 类型时，重新编译这段 switch，编译器会提醒你补上分支。

完整覆盖时为什么可以省略 default

对抽象 sealed interface，Java 语言规则可以根据 permits 集合判断 switch 是否穷尽。示例中的三个类型都被覆盖，因此不写 default 反而能保留更强的维护提示：未来新增 BankTransfer 并加入 permits 后，旧的 switch 在重新编译时会要求增加对应 case。

default 仍然有适用场景：

• 你确实希望未知类型落到统一的兜底结果，例如返回“暂不支持”。
• 接口层次来自跨模块或独立发布的组件，调用方不能随发布者同步重新编译。
• 你在兼容演进风险和编译期提醒之间，明确选择了运行时兜底。

但不要为了“看起来完整”机械添加 default。它会把新增类型从编译期提醒变成兜底路径，可能让新事件被悄悄归入旧逻辑。

null 和类型层次变化要单独处理

普通类型模式不会匹配 null。本例在进入 switch 前用 if 返回业务结果，也可以把空值作为显式 case 写进 switch：

static String describeWithNullCase(PaymentEvent event) {
    // case null 让空值策略与其它分支放在同一个表达式里
    return switch (event) {
        case null -> "缺少支付事件";
        case CardPaid paid -> "订单 " + paid.orderId() + " 已支付";
        case CashRefund refund -> "订单 " + refund.orderId() + " 已退款";
        case ManualReview review -> "订单 " + review.orderId() + " 待人工处理";
    };
}

另外，sealed 类型的“完整”是相对于编译器看到的类型层次而言。跨模块独立升级时，如果运行时加载到编译时未见过的 permitted 子类型，穷尽 switch 可能遇到 MatchException。对同一发布单元内同步编译的代码，这通常不是日常路径；对插件化或独立发布的边界，应该评估是否保留 default 并记录告警。

用最小命令检查结果

把上面的声明、describe 和 main 放在同一个 PaymentEventDemo.java 文件中，可以用以下命令编译运行：

# 使用 Java 21 或更高版本编译，示例不需要 --enable-preview
javac --release 21 PaymentEventDemo.java

# 运行后应看到支付、退款和人工处理三种结果
java PaymentEventDemo

订单 A-100 已支付 2599 分
订单 A-101 已退款 800 分
订单 A-102 待人工处理

如果删除其中一个 case，编译器会把 switch 表达式标记为不完整；如果新增一个 permitted 实现，也应先补分支再提交。这个检查点比依赖运行时某次测试刚好走到新类型更可靠。

常见取舍

简而言之，sealed interface 负责声明“有哪些合法分支”，类型模式 switch 负责把每个分支映射成结果。完整覆盖时不写 default，可以把类型层次的变化尽早交给编译器；null 与独立发布的兼容风险，则需要显式写出策略。

相关问题

• sealed interface 的实现类必须全部写在同一个文件吗？不必须，但它们需要满足 Java 对 permits、可访问性和同一模块/包边界的约束；工程上应让类型层次易于一起编译和维护。
• 为什么 switch 里已经覆盖三个类型还会报错？先检查选择器的静态类型、是否存在间接 permitted 子类、是否漏写 null 或使用了需要额外 preview 的语法。
• 什么时候应该保留 default？当未知实现来自独立升级边界且业务必须继续运行时，可以保留，但要把兜底结果、日志和后续处理写清楚。