Java switch pattern 怎样显式处理 null

Java 的模式 switch 处理引用类型时，null 不会自动匹配普通类型模式。要让空值进入可读、可维护的分支，应显式写出 case null；如果业务上想把空值和其它未识别值一起兜底，可以写 case null, default。没有这两个标签时，选择器为 null 仍会抛出 NullPointerException。

参考文档：https://docs.oracle.com/en/java/javase/25/language/pattern-matching-switch.html

先确认 null 的分支契约

模式 switch 的类型模式负责识别非空对象的类型，例如 case String s。它不是“只要类型能接收 null 就一定匹配 null”的隐式兜底。把 null 当作缺失值、非法值还是默认值，需要在标签中表达出来。

因此，排查空指针时先看选择器是否可能为空，再看 switch 是否声明了空值标签。不要只检查后面的类型模式；即使 case Object obj 在类型上看起来很宽，也不能代替明确的 case null。

用 case null 单独处理空值

最清晰的写法是把空值放在独立分支中。下面的表达式把缺失、文本和其它对象分开，调用方拿到的是稳定的分类结果。

static String classify(Object value) {
    // 让 null 的业务含义独立出来，避免落到类型分支后再猜测
    return switch (value) {
        case null -> "缺失";
        case String text -> {
            // 类型模式只处理已经确认非空的 String
            yield "文本:" + text;
        }
        default -> "其它";
    };
}

case null 不声明模式变量，因为这里没有可供读取的对象。它可以出现在普通类型模式之前或之后，但建议放在读者容易发现的位置，并让每个分支都表达单一意图。

需要统一兜底时使用 case null, default

有些解析器只关心“能否识别”，对空值和未知对象采用相同的降级策略。这时可以合并两个标签：

static String kind(Object value) {
    // null 与未知类型都返回同一个安全的兜底结果
    return switch (value) {
        case String text -> "文本:" + text;
        case Integer number -> "整数:" + number;
        case null, default -> "未识别";
    };
}

case null, default 表示“空值或其余未匹配值”，它应当是最后的标签。若空值需要记录缺失原因、返回特定错误码或触发不同监控，就不要合并，改用单独的 case null。

不要把 null 和普通类型模式硬塞进一个标签

当前语法中，null 标签与普通类型模式承担不同职责，不能写成把 null 和 String s 放在同一个标签里的形式。正确做法是拆成两个分支：

static String display(Object value) {
    // 空值和字符串分别处理，避免模式变量在空值路径上没有定义
    return switch (value) {
        case null -> "(空)";
        case String text -> text.isBlank() ? "(空白文本)" : text;
        default -> "(其它对象)";
    };
}

这里的边界还有两个容易混淆的点：第一，default 只负责没有其它标签匹配的非空值；第二，若把 null 与 default 合并，合并标签要放在末尾，后面不能再追加分支。

用三组输入做最小反向验证

写完后不要只测一个正常字符串。至少准备一个 null、一个已知类型和一个未列出的非空对象，分别确认返回值或异常是否符合设计：

• null：应命中 case null，或在合并兜底时命中 case null, default。
• 已知类型：应命中对应的类型模式，并能安全读取模式变量。
• 其它非空值：应命中独立的 default，或与空值一起进入合并兜底。

如果第一组输入直接抛出 NPE，优先检查选择器来源和 case null 是否真的写在当前 switch 中；如果编译器提示标签组合非法，就拆开空值与类型模式，而不是通过调整顺序掩盖问题。

一份可执行的检查清单

• 选择器是引用类型，并且调用链允许传入 null。
• 需要特殊业务含义时使用独立的 case null。
• 需要统一降级时使用末尾的 case null, default。
• 不把 case Object obj 或其它类型模式当作空值处理。
• 至少用空值、已知类型、其它非空值各验证一次。

这样处理后，null 的行为就从运行时意外变成了代码中的显式契约：读者能看见分支，编译器能检查结构，测试也能准确覆盖空值边界。

相关问题

没有写 case null 会怎样？ 当选择器求值为 null 且当前模式 switch 没有空值标签时，会抛出 NullPointerException，不会自动进入 default。

什么时候不要合并 null 和 default？ 当空值需要单独记录、返回不同错误信息或触发不同恢复动作时，保留独立的 case null 更清楚。