Java Pattern Matching for switch 如何处理 null：case null、default 与类型分支

订单状态分派上线后，最难受的往往不是新状态，而是一条历史数据里的 null。把传统 switch 改成 Java 的类型模式后，如果只写了几个对象类型和一个 default，这条空值并不会自动进入默认分支，调用链可能直接抛出 NullPointerException。

一个空状态把分派链打断了

假设订单状态用接口表示，线上服务要根据状态生成提示语。旧代码常见的写法是先判断空值，再进入普通 switch；改成模式匹配后，开发者容易把空判断删掉，认为 default 已经足够兜底。

static String message(OrderState state) {
    return switch (state) {
        case Paid paid -> "已支付：" + paid.amount();
        case Cancelled cancelled -> "已取消：" + cancelled.reason();
        default -> "待确认";
    };
}

当 state 为 null 时，这个表达式不是返回“待确认”，而是在进入匹配前就失败。问题的关键不在 default 写得够不够宽，而在 Java 保留了传统 switch 对 null 的特殊边界。

default 和 case null 各自负责什么

case null 是专门匹配空值的标签；它可以单独出现，也可以和某些模式标签组合。default 则处理其他没有命中的值，例如一个未被具体类型模式覆盖的非空实现。两者的输入集合不同，不能互相替换。

static String message(OrderState state) {
    return switch (state) {
        case null -> "状态缺失，转人工核对";
        case Paid paid -> "已支付：" + paid.amount();
        case Cancelled cancelled -> "已取消：" + cancelled.reason();
        default -> "待确认";
    };
}

这里的空值策略是显式的：返回一个可观测的业务结果，而不是把坏数据伪装成待确认。实际项目也可以在 case null 中抛出带字段名的异常，关键是不要让 null 的行为藏在运行时默认规则里。

when 守卫不能替代空值分支

模式匹配经常还要按金额、来源或状态字段做二次筛选。例如只把大额支付交给人工复核，可以在类型模式后加 when：

static String review(OrderState state) {
    return switch (state) {
        case null -> "缺少状态";
        case Paid paid when paid.amount() >= 10000 -> "大额复核";
        case Paid paid -> "普通支付";
        case Cancelled ignored -> "无需复核";
        default -> "待补充规则";
    };
}

when 是对已经匹配到的模式再加条件。空值没有可供读取的 Paid 对象，所以不能指望 case Paid paid when ... 顺手接住 null；空值仍要单独写标签。

兼容改造时先确定三个边界

第一，确认表达式类型是否允许出现空值。如果数据库旧记录、反序列化结果或缓存缺字段都可能产生 null，就把 case null 当作必测路径。

第二，确认是否真的需要 default。对封闭的 sealed 类型层次，编译器可能帮助你检查覆盖情况；对开放接口，default 仍是未知实现的运行时兜底，但它不会替你定义空值策略。

第三，确认分支顺序和守卫是否可读。先写 null，再写带条件的具体模式，最后写无条件的同类型模式和 default，读代码的人更容易看出每个输入的归属。

用边界测试证明分支真的闭合

@Test
void handlesNullAndKnownStates() {
    assertEquals("缺少状态", review(null));
    assertEquals("大额复核", review(new Paid(12000)));
    assertEquals("普通支付", review(new Paid(99)));
    assertEquals("无需复核", review(new Cancelled("用户撤销")));
}

测试重点不是把每个箭头分支机械跑一遍，而是验证输入集合的边界：null、触发 when 的值、未触发守卫的同类型值，以及其他实现。日志或指标里还应区分“状态缺失”和“未知状态”，这样数据清洗和代码漏分支不会混成一个问题。

常见问题

写了 default，为什么 null 仍然报错？

因为 default 不是 null 标签。模式 switch 需要显式的 case null 才会把空值纳入匹配范围。

case null 可以和 default 合并吗？

可以按语法和业务语义设计组合，但通常建议先分开写。状态缺失和未知非空类型往往需要不同的日志、指标或恢复动作，分开更容易验收。

when 条件里能判断 null 吗？

不要把它当作 null 入口。when 服务于已经匹配到的模式，空值路径应由 case null 直接表达。

所有 Java 版本都支持这种写法吗？

应以项目的 JDK 与语言级别为准。使用模式 switch 和 when 前检查构建工具配置、编译器版本与运行环境，并在 CI 中执行完整边界测试。

把空值策略写成代码的一部分

Pattern Matching for switch 的价值不只是少写几次强制类型转换，更重要的是把“这个值属于哪一类”写成可检查的分支。空值如果在业务上有含义，就用 case null 明确表达；未知非空类型再交给 default。最后用一组包含 null、守卫前后值和未知实现的测试，把这套分派契约固定下来。