怎么利用密封类体系在编译器层面获得完备性的穷举模式检查-java教程-PHP中文网

密封类本身不提供编译期穷举检查，但配合 when/match/联合类型判别式等可实现全覆盖验证；其前提是子类同文件定义、不可扩展、且必须用表达式语法而非is链。

怎么利用密封类体系在编译器层面获得完备性的穷举模式检查

密封类（Sealed Class）体系本身不直接提供“编译器层面的完备性穷举检查”，但配合 when 表达式（Kotlin） 或 模式匹配（Scala 3、Rust enum + match、TypeScript discriminated union + exhaustive checking），可在编译期强制要求覆盖所有已知子类型，从而实现逻辑上的“穷举完备性检查”。

核心机制：编译器知道所有可能的子类型

密封类的关键约束是：所有直接子类必须与密封类定义在同一个文件中（Kotlin）或同一作用域内（如 Scala 的 sealed trait / Rust 的 enum）。这使得编译器能静态确定该类型的所有可能具体值——没有外部未知子类可逃逸，因此 when / match 的分支可以被验证是否“全覆盖”。

Kotlin 中 sealed class + when：若未处理某个子类或缺少 else 分支（且类型非可空），编译报错
Rust 中 enum + match：必须列出所有变体，或用 _ 占位；若未来新增变体，所有 match 处都会立即报错
TypeScript 中联合类型 + discriminant field（如 type Shape = Circle | Square; interface Circle { kind: 'circle'; }）配合 --exactOptionalPropertyTypes 和类型守卫或 switch，结合插件（如 exhaustive-switch）可补全检查

确保真正“完备”的三个前提

仅声明 sealed 不够，需配合语言特性和编码约定：

子类必须为 final / 不可继承（Kotlin 默认密封子类是 final；Rust enum 变体天然封闭；若用 abstract class + sealed，在 Kotlin 中需显式禁止进一步继承）
when / match 必须是表达式上下文且返回类型统一（避免漏写分支后靠运行时默认行为兜底）
禁止使用 is-check + if 链替代 when：is 检查无法被编译器追踪覆盖度，会绕过完备性校验

常见陷阱与应对

看似用了密封类，却失去编译期保障的情况：

子类定义在其他文件（Kotlin）→ 违反密封规则，编译失败，但若误用 open class 模拟，则彻底丢失检查能力
when 中用了 else 分支且逻辑隐含“不可能情况” → 编译通过，但削弱了穷举意义；应改用 throw 或 assert(false) 并加注释说明为何此处不可达
密封类包含 data class 子类，但又在 when 外部用 == 或 toString 判断 → 这些操作脱离模式匹配体系，无法享受完备性检查