订单事件路由的空值契约：Java 模式分支、未知状态与回归验收

把订单状态从字符串改成更明确的强类型后，Java 的模式分支能大幅减少堆成串的 instanceof 判断和强制类型转换。不过迁移时最容易漏掉的不是各类业务类型分支，而是 null：传统 switch 对 null 的处理方式，和模式匹配代码给人的直觉并不一致。

为什么看似全覆盖的 switch 仍会被 null 打断

先看一个常见的订单事件模型：

sealed interface OrderEvent permits Paid, Cancelled, Refunded {}
record Paid(String orderId) implements OrderEvent {}
record Cancelled(String orderId, String reason) implements OrderEvent {}
record Refunded(String orderId) implements OrderEvent {}

如果方法入参是 OrderEvent event，下面的分支看起来已经覆盖了三个许可类型：

static String route(OrderEvent event) {
    return switch (event) {
        case Paid p -> "fulfillment";
        case Cancelled c -> "after-sale";
        case Refunded r -> "finance";
    };
}

密封接口能让编译器确认类型集合已经穷尽，但它不会自动把 null 归入任意一个类型模式。直接调用 route(null) 时，程序会在匹配任何业务分支前就抛出 NullPointerException。这个问题很容易等到接口迁移完上线之后才暴露，因为旧代码很可能在进入 switch 前就已经统一做过空值判断。

case null 应该放在分支里的哪个位置

如果 null 是可预期的合法输入，直接把它写为独立分支，把业务语义明明白白留在代码里就好：

static String route(OrderEvent event) {
    return switch (event) {
        case null -> "invalid-event";
        case Paid p -> "fulfillment";
        case Cancelled c -> "after-sale";
        case Refunded r -> "finance";
    };
}

case null 不需要额外伪造一个空对象，也不会把空值悄悄归到某个合法状态里。如果 null 代表上游调用方违反了接口契约，也可以在进入 switch 前用 Objects.requireNonNull 抛出带上下文的异常；核心是要把空值处理的选择写得明明白白，不要依赖黑箱一样的默认行为。

类型分支、守卫与 default 的边界

模式匹配的优势在于可以直接读取记录组件，写分支的时候要注意条件先后顺序，保持代码可读：

static String describe(OrderEvent event) {
    return switch (event) {
        case null -> "missing";
        case Paid p when p.orderId().isBlank() -> "paid-without-id";
        case Paid p -> "paid:" + p.orderId();
        case Cancelled c -> "cancelled:" + c.reason();
        case Refunded r -> "refunded:" + r.orderId();
    };
}

更具体的条件分支必须放在普通类型分支前面，不然排在前面的通用分支会先把匹配请求接走，导致后面的分支永远跑不到。对于非密封接口，编译器没法枚举未来可能新增的实现，通常需要加 default 兜底。但 default 只代表兜底路径，不能替代对应的日志埋点、指标上报或者明确的未知状态处理逻辑。

迁移时怎样验收 null 和未知类型

至少要准备四类测试用例：null 输入、每个已知实现类、字段异常的非法对象，以及非密封接口下的自定义未知实现。测试要明确校验返回结果或者抛出的异常类型，不能只验证方法执行完没有直接崩溃。

@Test
void null_is_routed_explicitly() {
    assertEquals("invalid-event", route(null));
}

@Test
void every_known_event_has_a_route() {
    assertAll(
        () -> assertEquals("fulfillment", route(new Paid("o-1"))),
        () -> assertEquals("after-sale", route(new Cancelled("o-2", "duplicate"))),
        () -> assertEquals("finance", route(new Refunded("o-3")))
    );
}

编译环境也要固定到 Java 21 或更高版本，在 CI 流程里显式记录运行时版本。如果项目还要兼容 Java 17，不能直接硬抄模式匹配的语法；要么保留旧的实现逻辑，要么通过分支发布策略单独验证字节码和启动环境。

常见问题

sealed 接口已经列完所有实现，为什么还要考虑 null？

密封类型约束的是非空对象的实现集合，null 不属于这些实现的任何一种，所以仍然需要独立处理。

能不能用 default 统一处理 null？

不能把 default 当作 null 分支的替代品。针对 switch 模式匹配的场景，null 的匹配行为要通过 case null 或者进入 switch 前的契约检查明确表达出来。

迁移后最值得先补哪条回归测试？

先补 null 输入的测试用例，再逐个覆盖所有已知类型；如果接口不是 sealed 修饰的，再补一个未知实现的兜底测试。

总结

Java 21 switch 模式匹配减少了类型分支的样板代码，但不会替你决定 null 对应的业务含义。把 case null 配置、具体分支排序、default 兜底逻辑和版本验收一起纳入迁移清单，才能让重构后的状态路由既简洁又可控。