Java Pattern Matching switch 处理密封层级

处理一组固定的业务事件时，传统 instanceof 加多层 if 很快会变成一张难维护的分支网。Java 的 sealed 类型可以先限定允许出现的子类型，再交给 Pattern Matching switch 按类型分派。关键不在于把所有分支写得更长，而在于认清：编译器只会沿着当前选择器类型能够到达的密封层级判断覆盖范围。

官方学习入口：https://dev.java/learn/

下面用订单事件做一个小场景：顶层事件只允许“支付事件”和“履约事件”，履约事件再细分为发货与退款。目标是让处理函数返回一个稳定的路由结果，并在层级新增类型时尽早暴露影响面。

先把密封层级画成一条分派路径

第一步不是马上写 switch，而是列出每一层的责任。顶层 OrderEvent 只负责约束范围，FulfillmentEvent 负责继续约束履约类事件，真正承载数据的记录类型位于叶子层。

// 用密封接口把订单事件限制在可维护的类型集合内
sealed interface OrderEvent permits PaymentReceived, FulfillmentEvent {}

// 履约事件继续分层，便于按业务边界组织处理逻辑
sealed interface FulfillmentEvent extends OrderEvent
        permits ShipmentCreated, RefundRequested {}

// record 是隐式 final 的叶子类型，不能再被扩展
record PaymentReceived(String orderId) implements OrderEvent {}
record ShipmentCreated(String orderId, String carrier) implements FulfillmentEvent {}
record RefundRequested(String orderId, int cents) implements FulfillmentEvent {}

这里容易误判的一点是：FulfillmentEvent 虽然是 OrderEvent 的直接子类型，但它不是叶子类型。处理 OrderEvent 时，如果只写 case FulfillmentEvent f，还不能表达发货和退款的不同动作；要么继续嵌套分派，要么直接在顶层展开叶子类型。

把类型模式展开为穷尽的 switch 表达式

如果每个叶子类型都有独立业务结果，直接展开最清楚。因为选择器的静态类型是密封接口，编译器可以根据 permits 关系判断这三个分支覆盖了全部可能类型，所以不必机械添加 default。

// 返回值让每个事件都得到明确的路由结果
static String route(OrderEvent event) {
    return switch (event) {
        // 支付事件进入结算路径
        case PaymentReceived p -> "settlement:" + p.orderId();
        // 发货事件进入物流路径
        case ShipmentCreated s -> "shipping:" + s.carrier();
        // 退款事件进入售后路径
        case RefundRequested r -> "refund:" + r.cents();
    };
}

这段代码表达了“叶子类型就是数据生命周期的终点”：事件从输入进入密封层级，匹配到叶子后转为一个业务路由结果。若业务上只需要区分“支付”和“履约”，也可以保留 case FulfillmentEvent，但那时需要在该分支内部继续做一次模式匹配，避免把两种履约事件混成一个结果。

// 只关心业务大类时，可以在履约分支内继续细分
static String group(OrderEvent event) {
    return switch (event) {
        case PaymentReceived p -> "payment";
        case FulfillmentEvent f -> switch (f) {
            // 内层选择器的静态类型是 FulfillmentEvent
            case ShipmentCreated s -> "fulfillment-shipping";
            case RefundRequested r -> "fulfillment-refund";
        };
    };
}

处理 null、default 与模式支配顺序

Pattern Matching switch 的选择器如果是 null，没有显式 case null 时仍会抛出 NullPointerException。如果订单事件来自反序列化或消息队列，通常应把空值作为输入层异常明确处理，而不是让它混入业务分支。

// 空值在入口处变成可识别的拒绝结果
static String safeRoute(OrderEvent event) {
    return switch (event) {
        // 明确区分空输入，避免异常被误认为未知事件
        case null -> "rejected:null-event";
        case PaymentReceived p -> "settlement:" + p.orderId();
        case ShipmentCreated s -> "shipping:" + s.carrier();
        case RefundRequested r -> "refund:" + r.cents();
    };
}

default 适合“未来类型统一走兜底”这种明确策略，但它也会隐藏密封层级新增后的编译提示。另一个常见问题是模式支配：更宽的类型模式放在前面，会让后面的窄类型永远匹配不到。

// 先写窄类型，再写宽类型，避免后者被前者覆盖
static String describe(Object value) {
    return switch (value) {
        // String 是 CharSequence 的子类型，必须先处理
        case String text -> "string:" + text.length();
        case CharSequence sequence -> "sequence:" + sequence.length();
        // 其他对象进入兜底分支
        default -> "other";
    };
}

新增实现时让编译器暴露影响面

密封层级的价值不只是限制继承，更是把变更影响面变成编译期信号。假设履约事件增加一个 AddressChanged 记录，并把它加入 FulfillmentEvent permits，所有依赖穷尽匹配的 switch 都应重新编译。缺少新分支时，编译器会指出选择器没有被完整覆盖；这比上线后把新事件落入错误的默认路径更容易处理。

// 新增叶子类型后，密封声明显式扩大允许集合
sealed interface FulfillmentEvent extends OrderEvent
        permits ShipmentCreated, RefundRequested, AddressChanged {}

// 新事件先拥有独立结果，再回到完整构建流程
record AddressChanged(String orderId, String city) implements FulfillmentEvent {}

// 编译器会提醒既有穷尽 switch 补上 AddressChanged 分支
static String routeAfterChange(OrderEvent event) {
    return switch (event) {
        case PaymentReceived p -> "settlement:" + p.orderId();
        case ShipmentCreated s -> "shipping:" + s.carrier();
        case RefundRequested r -> "refund:" + r.cents();
        case AddressChanged a -> "address:" + a.city();
    };
}

要注意编译期和运行期是两个生命周期。已经编译的调用方与后来变化的密封层级不一致时，运行阶段可能暴露匹配异常，因此密封层级和使用它的 switch 应放在同一次构建、测试和发布流程里，不能只替换一侧的类文件。

用小型测试矩阵检查叶子类型和迁移边界

最后把检查项收敛成一张小表，避免测试只覆盖最常见的支付事件。

实践中可以把“每个叶子类型至少一个测试、空值一个测试、每次新增 permits 成员必须完整构建”写进团队约定。这样 Pattern Matching switch 就不只是更短的语法，而是把密封层级、数据路由和迁移责任连接起来。

常见问题

为什么 sealed 接口已经列了 permits，还要写 default？

不一定要写。没有 default 时，新增允许类型会更容易触发编译提醒；若业务需要统一兜底或模块边界无法穷尽，再使用 default，并为兜底结果配套监控或测试。

直接匹配 FulfillmentEvent 会不会自动包含它的叶子类型？

会覆盖这些对象，但它们会共享同一个分支结果。若不同叶子需要不同动作，应继续嵌套匹配或在顶层展开叶子模式。

为什么代码更新后仍可能出现匹配异常？

如果使用穷尽 switch 的类没有和变化后的密封层级一起重新编译，编译时的覆盖分析与运行时类型集合可能不一致。把相关模块放在同一构建产物中可以降低这种迁移风险。