Java pattern switch用 switch 覆盖 sealed 类型分支的实现方法

Java 21 的 pattern switch 可以直接按类型拆分 sealed 层次。真正要记住的是：when 只负责把同一种类型继续细分，不能替代该类型的无守卫分支；穷尽性仍要覆盖所有 permitted 类型，null 也要单独决定是否处理。

写 sealed 类型的 switch 时，先列出 permits 的所有分支，再给具体类型增加守卫，最后保留无守卫兜底。这样既能通过穷尽性检查，也不会被支配关系拦住。

先让 sealed 层次成为可计算的分支集合

先把业务对象收敛成一个小而稳定的 sealed 层次。下面的 Shape 只允许三个直接实现，record 默认是 final，因此每个类型都能作为明确的模式分支。

sealed interface Shape permits Circle, Rectangle, Triangle {}

record Circle(double radius) implements Shape {}
record Rectangle(double width, double height) implements Shape {}
record Triangle(double a, double b, double c) implements Shape {}

// 注释：permits 是编译器判断 Shape 覆盖范围的类型边界。

这里的关键不是把类型写得复杂，而是让“所有可能的 Shape”变成可枚举集合。只要后续没有通过泛化接口或额外实现扩大这条边界，switch 就可以按这三个类型组织。

无守卫分支如何覆盖全部 permitted 类型

对 sealed 层次做最小的 switch 表达式时，直接为三个允许类型各写一个无守卫模式即可。这里不需要为了“保险”再补一个 default，因为三个类型已经覆盖了 Shape 的全部合法实现。

static String kind(Shape shape) {
    return switch (shape) {
        case Circle c -> {
            // 注释：无守卫分支覆盖所有 Circle 值。
            yield "circle";
        }
        case Rectangle r -> {
            // 注释：Rectangle 是 Shape 的第二个 permitted 类型。
            yield "rectangle";
        }
        case Triangle t -> {
            // 注释：三个类型合起来覆盖整个 sealed 层次。
            yield "triangle";
        }
    };
}

穷尽性看的是类型覆盖，不是每个分支里的业务条件。未来如果给 Shape 增加新的 permitted 类型，原来的 switch 就需要重新检查；这也是 sealed 层次变化后应重新编译相关代码的原因。

守卫只负责细分，不能替代兜底类型分支

假设只有半径为正的圆需要单独处理，可以把条件放在 when 后面。但这个守卫只覆盖一部分 Circle，所以还要保留同类型的无守卫分支接住其余圆。

static String describe(Shape shape) {
    return switch (shape) {
        case Circle c when c.radius() > 0 -> {
            // 注释：守卫只细分有效半径的 Circle。
            yield "positive circle";
        }
        case Circle c -> {
            // 注释：无守卫 Circle 负责兜住零值或其他半径边界。
            yield "non-positive circle";
        }
        case Rectangle r -> "rectangle";
        case Triangle t -> "triangle";
    };
}

顺序也有讲究：如果先写无守卫的 case Circle c，后面的带守卫 Circle 会被判定为 dominated，因为前者已经能匹配所有 Circle。反过来，先写带守卫、再写无守卫，才是“先细分、后兜底”的合法结构。

穷尽性、支配关系和 null 一起检查

遇到编译错误时，可以按下面的顺序判断。穷尽性解决“有没有漏类型”，支配关系解决“前面的分支是否已经吃掉后面的分支”，两者不是同一个问题。

如果要把空值变成业务分支，可以在同一个 switch 中加入 case null -> "empty"。它表达的是输入边界，不属于 Shape 的 permitted 类型集合，因此应该单独审视。

常见问题

为什么只写带 when 的 Circle 仍然可能不穷尽？

因为守卫可能为 false，它只覆盖 Circle 的一个子集。必须补无守卫 Circle，或使用能覆盖全部值的其他分支。

为什么 case Circle c 会让后面的 when 分支报 dominated？

无守卫 Circle 已经覆盖全部 Circle，后面的条件分支没有剩余可匹配范围。把带守卫分支放到前面即可表达细分关系。

sealed 类型增加实现后 default 要不要保留？

如果希望编译器提醒每次层次扩展，优先保留显式类型分支并重新编译；default 能兜底，但会降低新增类型时的可见提醒。

参考规范：https://docs.oracle.com/javase/specs/jls/se21/html/jls-14.html；语言指南：https://docs.oracle.com/en/java/javase/21/language/pattern-matching-switch.html。