Java switch 表达式怎样处理枚举穷尽性

在多模块 Java 服务里，枚举往往承担“状态集合”的职责：路由区域、订单阶段、任务类型都可能被多个调用方映射成整数、标签或策略对象。此时最怕的不是少写一个分支，而是新增枚举常量后，某个返回值型分支悄悄失去覆盖。

switch 表达式正好把这个维护问题交给编译器检查：它必须对所有可能输入穷尽；如果选择器是枚举，并且代码覆盖了全部已知枚举常量，编译器可以插入隐式 default。因此，枚举映射不必为了“看起来完整”机械添加一个永远走不到的兜底分支。

最小原则是：枚举的每个已知常量都给出一个值，使用箭头规则减少贯穿；需要多条语句时用块体和 yield。只有业务确实需要未知值兜底、显式报错或兼容非枚举输入时，才写 default。

官方地址：https://docs.oracle.com/en/java/javase/21/language/switch-expressions.html

先把枚举状态映射成一个明确结果

假设服务需要根据区域枚举选择分片编号。旧代码常见的写法是先声明变量，再用 switch 语句赋值；当状态集合扩展到多个模块时，变量初始化、break 和默认值很容易分散在不同位置。

enum Region {
    AP_SOUTH, EU_WEST, US_EAST
}

final class ShardRouter {
    static int shardOf(Region region) {
        // switch 表达式直接产出分片编号，调用方不需要接收一个先声明的临时变量。
        return switch (region) {
            // 每个箭头分支只产出一个值，不会继续落入下一个 case。
            case AP_SOUTH -> 1;
            case EU_WEST -> 2;
            case US_EAST -> 3;
        };
    }
}

这里没有写 default，仍然可以构成穷尽的枚举表达式，因为三个分支覆盖了 Region 当前已知的全部常量。返回值的类型由各分支共同决定，shardOf 的返回类型则明确告诉调用方这是一组整数映射。

箭头规则让分支边界更容易审查

箭头规则的价值不只是少写 break。在代码审查时，每个 case 都有独立的右侧产出，读者不必沿着下面的语句判断是否会贯穿到别的常量。

static String routeLabel(Region region) {
    return switch (region) {
        // 多个常量可以共享同一个结果，但仍然是一个清楚的分组。
        case AP_SOUTH, EU_WEST -> "asia-europe";
        case US_EAST -> "america";
    };
}

共享结果时可以合并常量，但不要为了减少行数把业务上不同的状态硬塞到同一组。穷尽性解决的是“有没有覆盖所有可能值”，不解决“这些值是否应该共享策略”的建模问题。

块体分支必须用 yield 产出值

当分支需要记录局部变量、做一次规范化或调用辅助方法时，箭头右边可以写块体。块体不能只执行语句然后自然结束，因为 switch 表达式必须得到一个值，或者通过抛异常提前结束。

static int shardWithAudit(Region region) {
    return switch (region) {
        case AP_SOUTH -> {
            // 复杂分支先准备审计标签，再用 yield 交出表达式结果。
            String auditLabel = "route-ap";
            recordRoute(auditLabel);
            yield 1;
        }
        case EU_WEST -> {
            // 每个正常完成的块体都必须明确产出一个 int。
            recordRoute("route-eu");
            yield 2;
        }
        case US_EAST -> 3;
    };
}

static void recordRoute(String label) {
    // 示例只表达调用关系；真实项目可接入已有审计组件。
    System.out.println(label);
}

yield 只属于 switch 表达式的值产出语义，不能把它当成普通循环里的 break 替代品。若块体没有 yield，也没有直接抛出异常，编译器会拒绝这段表达式。

“穷尽”与“显式 default”不是一回事

枚举表达式覆盖全部已知常量时，编译器会插入隐式 default。这让代码能够保持“新增常量就重新检查映射”的形状：开发者看到的每个枚举项都是真实业务分支，而不是被一个宽泛兜底吞掉。

不过，显式 default 仍然有合理场景。例如，业务希望遇到无法识别的状态时统一抛出异常，或者映射值本身就是“未知”标签，可以把策略写出来：

static String displayName(Region region) {
    return switch (region) {
        case AP_SOUTH -> "亚太南部";
        case EU_WEST -> "欧洲西部";
        case US_EAST -> "美国东部";
        default -> throw new IllegalStateException("Unsupported region: " + region);
    };
}

在这段代码里，default 对当前枚举常量来说不是必需的，但它表达了一个明确的业务意图：如果编译产物面对超出当前映射的值，宁可失败也不返回误导性的名称。是否采用它，要看团队更重视显式兜底还是让编译器直接暴露缺口。

新增枚举常量时，真正要审查的是映射集合

在大型代码库里，枚举定义和多个 switch 表达式经常不在同一个模块。增加 Region 常量后，重新编译能够帮助定位覆盖不完整的表达式，但前提是这些模块确实参与了编译；只运行一个没有重新编译依赖模块的旧产物，不能代替代码审查。

我会把每个枚举映射看成一个小型契约：输入集合是枚举常量，输出集合是分片号或标签，default 是明确写出的异常/兜底策略。这样做的好处是，新增常量时先找编译错误，再检查那些使用显式 default 的位置，避免“编译通过但业务落入通用默认值”的情况。

如果一个映射需要根据外部字符串、数据库字段或未来版本状态做容错，就不要把“枚举穷尽性”误当成外部输入校验。先把外部值解析成已知枚举，再决定解析失败是返回错误、记录降级还是交给上层处理。

null 输入要单独决定策略

null 不是枚举常量，因此不能用“枚举项已经全部列出”推断 null 一定有业务结果。对 Java 21 的常规枚举映射来说，调用方应尽早决定是否禁止 null；如果确实需要把 null 作为一种可识别状态，应采用项目目标版本支持的明确 case null 写法，并为它配套说明。

static String safeDisplayName(Region region) {
    // 先把 null 变成业务可读的输入错误，避免把空值混进枚举穷尽性判断。
    if (region == null) {
        throw new IllegalArgumentException("region must not be null");
    }

    return switch (region) {
        // 已知枚举常量仍然逐项覆盖，表达式的结果契约保持清楚。
        case AP_SOUTH -> "亚太南部";
        case EU_WEST -> "欧洲西部";
        case US_EAST -> "美国东部";
    };
}

这个写法把 null 校验放在表达式之外，适合需要统一输入校验的服务边界。不要为了“看起来穷尽”把 null、未知外部字符串和未来枚举项混成一个 default，否则异常原因会变得难以区分。

把选择落成一张维护清单

这套清单的重点不是让每个 switch 都长得一样，而是让“编译器负责覆盖检查、业务代码负责结果策略”这两个职责分开。规模变大后，清晰的失败方式通常比少写几行更有价值。

常见疑问

枚举 switch 表达式一定要写 default 吗？

不一定。覆盖全部已知枚举常量时，Java 可以把它视为穷尽表达式并插入隐式 default；是否显式写兜底取决于你是否要表达异常或降级策略。

为什么块体里的 println 之后还要写 yield？

因为表达式必须产出一个值。普通语句不会自动成为表达式结果，块体需要用 yield 明确交出值。

新增枚举常量后，旧 switch 一定会自动报错吗？

重新编译包含该表达式的代码时，穷尽性检查才会重新运行。不要把线上旧字节码的运行结果当成编译期覆盖检查，涉及跨模块发布时要把相关模块纳入构建与回归范围。

总结

Java switch 表达式处理枚举穷尽性的核心，是让每个已知常量都有清楚的值产出。箭头规则负责收紧分支边界，块体用 yield 交出结果；覆盖全部已知常量时可以依赖隐式 default，但显式 default 仍适合表达失败或降级策略。最后单独处理 null 和外部输入，才能让“编译器检查覆盖”与“业务决定容错”各自保持清晰。