如何在 Java 中通过 switch 匹配 String 类型变量并规避 null 引用导致的空指针异常

Ja va 7起switch支持String但不处理null，必须提前判空；推荐在switch前用if处理null，或用Objects.requireNonNullElse提供默认值，避免case null、equals替代及catch NPE等错误做法。

从 Ja va 7 开始，switch 语句终于可以匹配 String 类型了，这无疑是个好消息。但先别急着庆祝，这里头有个“坑”得特别注意：它的底层实现，其实还是调用了 String.equals() 方法。这意味着什么？意味着如果你直接把一个 null 值扔进去，程序会毫不犹豫地抛出一个 NullPointerException。所以，问题的核心就变得非常清晰：**关键在于提前拦截，别让 null 有机会进入 switch 的流程**。

在 switch 前统一校验 null

最稳妥、也最推荐的做法，就是在 switch 之前，用 if 语句把 null 这个“不速之客”单独拎出来处理掉。

• 先判断字符串是否为 null（或者是否为空，根据业务需要），然后再放心地进入 switch 流程。
• 这里有个语法上的限制要记住：Ja va 不允许在 case 标签里直接写 case null:，所以想在里面处理是行不通的。
• 来看一个标准的示例写法：

String status = getUserStatus(); // 可能为 null
if (status == null) {
    handleUnknownStatus();
} else {
    switch (status) {
        case "ACTIVE":
            activateUser();
            break;
        case "INACTIVE":
            deactivateUser();
            break;
        default:
            handleUnknownStatus();
    }
}

使用 Objects.requireNonNullElse() 提供默认值

如果业务逻辑允许，可以把 null 看作是一种特定的默认状态（比如 “UNKNOWN”）。这时候，Objects.requireNonNullElse() 方法就派上用场了。

• 它的作用很直接：如果原值是 null，就返回你预设的默认非空字符串；否则返回原值。转换之后再交给 switch，逻辑就变得扁平多了。
• 当然，这种方法只适用于 null 在业务上有明确、合理的默认映射场景，不能滥用。

String status = getUserStatus();
String safeStatus = Objects.requireNonNullElse(status, "UNKNOWN");
switch (safeStatus) {
    case "ACTIVE":
        // ... 处理激活状态
        break;
    case "UNKNOWN":
        // 这里显式地处理原本是 null 的场景
        break;
    default:
        // ... 处理其他状态
}

封装为工具方法提升复用性

当项目里有多个地方都需要对 String 进行空安全的 switch 操作时，重复写判空逻辑就显得有点啰嗦了。更好的做法是，把通用逻辑封装起来。

• 比如，可以定义一个方法，它接收待判断的 String 和一个处理 null 的 Consumer，内部完成判空和逻辑分发。
• 或者，返回一个 Optional，把如何处理空值的决定权交给调用方。
• 这里有个简单的封装思路供参考：

public static void switchOnString(String s, Consumer onNull,
                                  Map cases) {
    if (s == null) {
        onNull.accept(null);
        return;
    }
    cases.getOrDefault(s, () -> {}).run();
}

避免常见误区

有些写法看起来似乎能解决问题，但实际上要么不可靠，要么不推荐，咱们得擦亮眼睛避开它们。

立即学习“Ja va免费学习笔记（深入）”；

• 用 `"some".equals(input)` 链式调用来替代 switch：对于一两个简单判断还行，但如果分支一多，代码的可读性会急剧下降，而且很容易忘记写默认的 default 逻辑。
• 试图在 case 里用 `Objects.equals("A", input)`：这是行不通的，因为 case 标签要求是编译期常量表达式。
• 依赖 try-catch 块来捕获可能发生的 NPE：这种做法性能开销大，而且用异常来处理正常的控制流，属于设计上的缺陷，违背了快速失败（fail-fast）的原则。