历史
switch 结构由基于 C 的控制流语句演变为一个能够在 Java 14 中产生值的完整表达式。随着 Java 17 引入密封类和接口以限制继承，并且 switch 的模式匹配作为预览特性出现，最终在 Java 21 中标准化。这一演变使 switch 从基于离散常量的简单跳转表，变为一种复杂的模式匹配机制，作为表达式使用时必须保证完整性。
问题
当 switch 作为表达式运行时（使用箭头语法 -> 或 yield），它必须为每个可能的输入生成一个值，以满足 Java 的静态类型系统。与传统的 switch 语句可能静默跳过未处理的情况或穿透不同，表达式需要绝对确定所有执行路径返回一个值。密封层次结构明确列举了所有允许的子类型，创造了一个封闭的宇宙，使得总覆盖可以在编译时理论上可验证。编译器必须将这个封闭的世界与开放模式（如类型模式或 null 情况）调和，以确保不会由于未覆盖的类型而导致运行时的 MatchException。
解决方案
编译器在编译的属性阶段执行主导性和完全性分析。它将密封类的 permits 子句视为有限的、封闭的类型集。对于 switch 中的每个模式，它从允许的类型宇宙中减去匹配的类型。如果在最后一个模式后仍有未匹配的允许子类型，并且没有无条件的 default 或完全的类型模式，编译器会拒绝代码并报错。此分析尊重模式主导规则（具体模式必须先于更一般的模式），并生成合成机制以分别处理类型模式的 null 输入。
sealed interface Payment permits Credit, Debit, Crypto {} record Credit() implements Payment {} record Debit() implements Payment {} record Crypto() implements Payment {} // 如果缺少 Crypto 情况，将导致编译时错误 double fee = switch (payment) { case Credit c -> 0.02; case Debit d -> 0.01; // 缺少 Crypto 情况导致："switch 表达式未覆盖所有可能的值" };
问题描述
在一个支付处理微服务中，我们需要根据工具类型计算费用：Credit、Debit、BankTransfer 和 Crypto。域模型使用了一个密封接口 PaymentInstrument，仅允许这四个实现。一个初级开发人员使用 switch 表达式实现了费用计算器，但不小心省略了 Crypto 情况，假设它会隐式产生零。当生产中启用加密货币支付时，这一遗漏导致运行时发生 MatchException，使交易管道崩溃并需要紧急回滚。
考虑的不同解决方案
解决方案 A：默认情况回退
我们可以添加一个 default -> 0.0 子句来处理任何未匹配的工具。这种方法提供了即时安全性，防止崩溃。然而，它模糊了业务意图，默默地吸收未处理的类型。如果日后在密封层次结构中添加了新的工具类型，则默认子句会将其隐藏，从而可能导致收入泄漏或合规违规。
解决方案 B：基于枚举的类型映射
迁移到枚举 InstrumentType 将通过常量枚举启用编译时的完全性检查。然而，这会创建一个平行的分类，需要每个支付工具公开冗余的类型元数据。它牺牲了密封类的多态性，每个子类型携带独特的数据字段，如卡号或区块链地址，迫使不自然的数据反规范化。
解决方案 C：编译器强制的完全模式 我们使用显式为所有四种允许类型的情况实现 switch 表达式，利用编译器的密封层次结构分析。这种方法将缺失的情况视为编译错误，在密封许可更改时迫使代码库更新。它消除了运行时的意外，通过将验证转移到构建阶段来提高安全性。
选择的解决方案和结果
我们选择了 解决方案 C，并配置构建管道将关于非完全 switch 表达式的编译器警告视为致命错误。当产品团队稍后将 BuyNowPayLater 作为第五个允许的子类型添加时，CI/CD 管道立即标记了十七个费用计算不完整的位置。这迫使税务、合规和会计模块进行协同更新，以确保新工具收到适当的财务逻辑。编译时的保证避免了静默默认，并在分布式团队中维护类型安全。
null 处理如何与模式开关中的完全性检查相互作用？
许多候选人错误地假设覆盖密封类的所有子类型就满足了完全性要求。然而，switch 表达式将 null 选择器视为不同于类型模式；必须有单独的 case null 子句或完全模式。没有显式的 null 处理，编译器会生成一个合成的 null 检查，从而抛出 NullPointerException，这意味着表达式对于类型在技术上是完全的，但对于 null 值本身却不是。
在针对密封层次结构的 switch 中添加默认子句为何可能违反密封类型的原则？
候选人通常将 default 作为防御性编码习惯添加，而没有意识到这会破坏密封类的封闭世界假设。默认子句可以匹配任何类型，包括将来版本中添加到 permits 列表的类型，这样有效地将编译时的完全性验证转换为运行时的捕获。这重新引入了密封类所设计用以消除的确切脆弱性，即允许未处理的新类型静默执行意外逻辑。
当针对某个允许但在当前模块不可见的密封类型的 switch 表达式时，会发生什么？
这种情况涉及可见性边界，其中密封类允许一个包私有的子类型在另一个包或模块中，但未导出给当前编译单元。编译器无法验证完全性，因为在使用位置未知完整的允许类型集，尽管所有本地可见的类型都已处理，仍会导致编译错误。解决此问题需要添加默认子句（破坏完全性）或调整 JPMS 模块导出以使 permits 可见，突显了模块可访问性与模式匹配之间的相互作用。