sealed class 模式匹配怎样让 switch 在类型层次变化时及时报错怎样完成一个可复用的最小示例

如果希望 Java 的 switch 在类型层次新增实现类时尽早暴露问题，关键是同时满足两个条件：用 sealed 类型固定直接子类型集合，再用模式匹配覆盖每一个 permitted 子类型，并且不要用 default 把缺失分支吞掉。这样重新编译时，新增子类型会让不完整的 switch 直接暴露在构建阶段。

最小可复用做法是：sealed interface 声明允许的实现者，final class 或 record 关闭每个分支，switch 表达式逐一匹配这些类型。把示例重新编译作为 CI 检查，就能在代码合入前发现类型层次变化没有同步到分派逻辑。

官方地址：https://openjdk.org/jeps/441

这里的“及时报错”指源码重新编译时的穷举检查，不是承诺所有已经编译好的旧二进制都会在链接阶段报错。旧二进制和跨模块发布另有边界，文章后面会单独说明。

触发信号：先判断 switch 是否真的能穷举

值班或构建日志里出现“新增一种事件后没有对应处理分支”时，先看 switch 的 selector 静态类型。只有当它是抽象的 sealed class 或 sealed interface，编译器才能根据 permits 继续判断允许的直接子类型；普通接口仍然可能被任意外部实现。

第二个判断是分支是否覆盖了所有可达类型。对一个抽象 sealed 接口，如果所有 permitted 子类型都是 final、sealed 或隐式 final 的 record，那么每个类型模式都能成为穷举集合的一部分。non-sealed 会重新打开扩展面，不能把它当成一个已经封闭的叶子类型来推断。

处理步骤：用 sealed 层次固定可维护的最小模型

下面的模型把告警事件拆成三个互斥分支。接口负责声明封闭范围，三个 record 直接成为叶子类型。示例使用 Java 21 的模式匹配 switch 语法，代码重点是“类型集合和分支集合必须同步”。

// 事件接口只允许当前模块声明的三种直接实现者。
sealed interface Alert permits CpuAlert, DiskAlert, NetworkAlert {}

// record 隐式为 final，适合作为穷举 switch 的叶子分支。
record CpuAlert(int load) implements Alert {}
record DiskAlert(long freeBytes) implements Alert {}
record NetworkAlert(String region) implements Alert {}

final class AlertRenderer {
    static String render(Alert alert) {
        // 不写 default，保留编译器对新增 permitted 类型的提示。
        return switch (alert) {
            case CpuAlert cpu -> "CPU 使用率: " + cpu.load() + "%";
            case DiskAlert disk -> "磁盘剩余: " + disk.freeBytes() + " bytes";
            case NetworkAlert network -> "网络区域: " + network.region();
        };
    }
}

这段代码的可维护点有三个：permits 是类型层次的单一清单；每个 record 是一个明确叶子；switch 不放无差别的 default。如果后来新增 MemoryAlert 并把它加入 permits，重新编译时就会发现 render 没有覆盖它。

快速判断：新增类型后应该看哪里

处理一次类型变更时，建议按下面的检查顺序定位，而不是先在每个调用点盲目加分支：

如果 selector 的静态类型被提升成了普通父接口，或者某个 permitted 分支是 non-sealed，编译器看到的闭包就会改变。此时应先修正类型边界或明确设计一个兜底策略，而不是把编译器提示简单视为误报。

构建确认：把重编译放进处理路径

这个机制依赖编译期检查，所以要让类型层次和分派代码在同一次构建中被重新编译。下面是一条最小的 Java 21 编译命令；它只表达构建入口，不代表本文已经在某台机器上运行过。

# 用固定的 Java 21 语言级别重新编译类型层次和分派代码。
javac --release 21 Alert.java AlertRenderer.java

# CI 中可把编译失败作为合并门禁，不要只运行已经存在的旧 class 文件。
java --version

团队里可以把这条检查放进常规构建任务：类型声明变更、业务分派变更和测试一起重新编译。这样缺少 MemoryAlert 分支的问题会在构建阶段出现，而不是等到某条罕见事件真正进入生产才被发现。

需要留意的是，源码编译检查和旧二进制运行不是同一件事。OpenJDK 对 sealed 类型演进的说明指出，给 sealed 层次增加 permitted 子类型不一定让已经存在的 class 文件在链接阶段失败；如果旧代码遇到编译时未知的新子类型，运行时仍可能进入匹配失败路径。因此，跨模块发布时既要重新编译消费者，也要保留运行时的可观测错误记录。

回滚路径：什么时候可以使用 default

如果目标是让新增类型在重编译时尽早报错，默认路径不应先写 default。因为 default 会让 switch 在语法上变得穷举，新增 permitted 类型不会再迫使每个消费者补充显式分支。

但边界适配层有时必须容忍独立发布的类型变化。这种情况下可以保留 default，同时把它写成明确的失败或降级策略，而不是静默返回正常结果：

static String renderAtBoundary(Alert alert) {
    // 适配独立发布模块时，兜底必须留下可观测的失败原因。
    return switch (alert) {
        case CpuAlert cpu -> "CPU 使用率: " + cpu.load() + "%";
        case DiskAlert disk -> "磁盘剩余: " + disk.freeBytes() + " bytes";
        case NetworkAlert network -> "网络区域: " + network.region();
        default -> throw new IllegalStateException("未知 Alert 类型: " + alert.getClass().getName());
    };
}

这是一条兼容性取舍，不是编译期守卫的替代品。内部代码优先不写 default；必须跨版本容忍时，才使用带日志、指标或明确异常的兜底，并在升级消费者后删掉它。

告警确认与复盘项

把下面几项作为代码审查和 CI 的固定检查，可以避免“看起来用了 sealed，实际没有形成保护”的情况：

1. selector 的静态类型确实是目标 sealed class 或 sealed interface，没有被提升为开放父接口。
2. 每个直接 permitted 子类型都明确为 final、record 或继续 sealed；对 non-sealed 分支单独定义边界策略。
3. 内部穷举 switch 没有无意义的 default，新增类型会触发重新编译提示。
4. 构建使用固定的 JDK 21+ toolchain，而不是只执行旧的 class 文件。
5. 跨模块升级时同时检查旧二进制、运行时异常观测和消费者重编译计划。
6. null 行为有明确约定：普通类型模式不会自动把 null 当成某个子类型，需要时单独处理 null case。

复盘时重点问一句：这次类型层次变化有没有和所有分派点一起进入同一次构建？如果答案是否定的，sealed 只能提供局部的类型表达力，不能替代构建门禁。

常见问题

为什么加了 sealed 还没有编译错误？

先确认是否真的新增了 permitted 子类型、switch 的 selector 是否仍是 sealed 类型，以及分支里是否已经存在 default。任何一个条件不满足，都可能看不到预期的缺分支提示。

为了兼容旧版本，应该一直保留 default 吗？

不要把两种目标混在一起。内部代码想要编译期提醒时省略 default；边界适配层需要容忍独立发布时才保留带观测的失败兜底，并把消费者重编译列入升级动作。

sealed class 和 sealed interface 的 switch 写法有区别吗？

穷举思路相同，都是根据 selector 的静态类型和允许的直接子类型判断覆盖集合。具体分支仍需匹配真实的类或接口层次，不能只凭变量名推断。