第一章Java 25密封类的演进与本质突破Java 25 将密封类Sealed Classes从预览特性正式转为标准语言特性并在语义表达力、编译期约束强度和运行时反射支持三方面实现质的飞跃。相比 Java 17 引入时的初步形态Java 25 的密封类不再仅依赖sealed、permits关键字进行静态声明而是通过 JVM 层级的ACC_SEALED标志与增强的Class.getPermittedSubclasses()API确保类型封闭性在加载、链接与反射各阶段均不可绕过。核心语法强化Java 25 允许在接口、记录record和普通类上直接声明密封性且子类型可跨模块声明——只需模块描述符中显式导出并使用opens或exports配合to子句public sealed interface Shape permits Circle, Rectangle, Triangle { } // 同一模块内 public final class Circle implements Shape { /* ... */ } // 跨模块子类需在 module-info.java 中声明 // opens com.example.shape to com.example.extended;编译期与运行时保障对比保障维度Java 17预览Java 25正式非法继承检测时机仅编译期报错编译期 类加载期双重拒绝反射获取许可子类getPermittedSubclasses()返回 null若未启用预览始终返回非空Class[]含完整泛型信息典型误用场景与修复遗漏permits列表导致编译失败必须显式列出所有直接子类型不可省略子类未声明final、sealed或non-sealed修饰符JVM 将拒绝加载该类模块间许可未正确声明需在父类所在模块的module-info.java中添加opens pkg to target.module;第二章sealed interface 的语义重构与建模能力跃迁2.1 密封接口作为领域契约从抽象类到接口的范式迁移当领域模型需强制约束实现边界时密封接口sealed interface替代抽象类成为更精准的契约表达方式——它既保留多态性又杜绝意外继承。契约表达力对比特性抽象类密封接口实例化限制不可直接实例化不可实现/扩展除非在声明模块内领域语义“是一个”is-a“属于一组有限变体”one-ofGo 中的等效建模通过接口私有类型type PaymentMethod interface { Kind() string } type creditCard struct{} // unexported type cryptoWallet struct{} // unexported func (creditCard) Kind() string { return credit_card } func (cryptoWallet) Kind() string { return crypto_wallet } // 外部包无法定义新实现形成事实密封该模式通过包级作用域控制实现可见性仅当前包可构造具体类型外部仅能使用接口从而模拟密封语义。Kind() 方法提供运行时类型识别能力支撑领域路由逻辑。2.2 permits 子句的精确控制力编译期约束 vs 运行时开放性权衡编译期强制契约permits 明确限定密封类sealed class的直接子类集合由编译器静态验证public sealed interface Shape permits Circle, Rectangle, Triangle { }该声明禁止任何未在 permits 中列出的类继承 Shape且所有许可子类必须显式声明 permits Shape 或使用 final/sealed/non-sealed 修饰符。运行时灵活性保留尽管编译期严格JVM 层面仍允许动态代理与反射绕过部分限制需 RuntimePermission(accessDeclaredMembers)维度编译期运行时子类合法性强制检查不校验字节码来源实例化控制无直接影响依赖构造器访问权限2.3 与 record、enum、non-sealed 的协同建模构建可验证的类型图谱类型契约的分层表达record 定义不可变数据骨架enum 刻画有限状态空间non-sealed 显式开放扩展边界——三者组合形成可静态校验的类型图谱。public non-sealed interface PaymentEvent {} // 允许跨模块实现 public record OrderPlaced(String orderId, BigDecimal amount) implements PaymentEvent {} public enum PaymentStatus { PENDING, CONFIRMED, FAILED }该声明确立了事件载体OrderPlaced与状态维度PaymentStatus的正交性编译器可验证所有 PaymentEvent 子类型是否覆盖业务语义全集。可验证性保障机制特性验证能力协同效果record字段完整性与不可变性确保事件载荷无歧义enum状态值穷举性杜绝非法状态字面量2.4 模块化边界下的 permits 可见性规则跨模块密封关系的声明与验证permits 语义本质permits 并非访问修饰符而是模块系统对密封类sealed class跨模块继承的显式授权契约。它将“谁可扩展”从运行时检查前移至编译期模块图验证。跨模块声明示例// module-a/src/main/java/com/example/shape/Shape.java package com.example.shape; public sealed interface Shape permits Circle, Rectangle {}该声明本身不暴露实现类Circle 和 Rectangle 必须在同一模块或被 permits 显式授权的其他模块中声明并通过 requires transitive 传递可访问性。模块描述符约束模块声明是否合法原因module module.a { exports com.example.shape; }否未声明opens或uses密封类型无法被外部模块继承module module.b { requires transitive module.a; }是仅当module.a同时opens com.example.shape to module.b时才允许实现2.5 密封接口的反模式识别何时不该用 sealed interface——基于DDD聚合根与值对象的实证分析聚合根的演化性冲突当聚合根需支持跨版本事件溯源或运行时动态行为注入如插件化策略sealed interface会阻碍合法扩展。Kotlin 示例sealed interface OrderStatus { data object Created : OrderStatus() data object Confirmed : OrderStatus() }该定义禁止外部模块添加PaidViaCrypto等新状态违反聚合根“随业务演进”的DDD原则。值对象的不可变性误用值对象应天然可扩展如新增货币精度策略但密封接口强制穷举封闭类型系统阻断领域方言适配如区域化金额格式编译期校验替代了运行时语义验证增加测试负担适用边界对照表场景适合 sealed interface应避免 sealed interface状态机有限、稳定、无外部扩展需求需支持插件/多租户定制值对象纯数据建模且无业务逻辑扩展点含计算策略或格式化变体第三章领域模型重构实战以电商订单域为例3.1 订单状态机的密封建模State 接口 具体状态实现的不可扩展性保障核心设计意图通过接口抽象与具体类型封闭杜绝非法状态注入和运行时意外分支确保状态流转仅限于预定义集合。Go 语言实现示例// State 定义唯一行为契约 type State interface { Handle(ctx context.Context, order *Order) error } // 具体状态类型全部为 unexported struct禁止外部构造 type pendingState struct{} type shippedState struct{} type cancelledState struct{} var ( PendingState State pendingState{} ShippedState State shippedState{} CancelledState State cancelledState{} )该模式利用 Go 的包级可见性小写首字母结构体 包内预实例化变量使外部无法 new 任意状态强制状态演进路径可控。状态迁移约束对比方式可扩展性安全性开放接口 外部实现高但危险低易引入非法状态密封接口 包内枚举零受控高编译期锁定3.2 支付策略的领域隔离PaymentMethod sealed interface 与风控策略注入的解耦设计领域边界显式化通过 Kotlin 的sealed interface定义支付方式契约强制所有实现类归属同一受限继承体系天然支持 exhaustive when 表达式杜绝运行时类型遗漏。sealed interface PaymentMethod { val code: String val displayName: String }code用于路由匹配如 alipaydisplayName供前端展示接口不可被外部模块随意实现保障领域内聚性。风控策略动态装配采用构造函数参数注入风控策略而非硬编码或 Service Locator 模式每个PaymentMethod实现仅依赖抽象RiskEvaluator策略实例由 DI 容器按上下文如商户等级、交易金额绑定策略组合能力对比方案编译期安全策略热替换测试隔离性if-else 分支❌❌❌Sealed 策略注入✅✅✅3.3 商品变体建模ProductVariant 密封族在 SKU 多态性与库存一致性间的平衡在电商系统中ProductVariant作为密封族sealed family通过编译期约束确保所有变体类型显式声明避免运行时类型逸出。核心类型定义sealed interface ProductVariant { val sku: String val stock: Int } data class ColorSizeVariant( override val sku: String, override val stock: Int, val color: String, val size: String ) : ProductVariant data class BundleVariant( override val sku: String, override val stock: Int, val includedItems: ListString ) : ProductVariant密封族强制穷尽匹配使when表达式可静态验证覆盖全部子类型保障库存更新逻辑不遗漏任一变体形态。库存一致性保障机制变体类型库存粒度并发控制策略ColorSizeVariantSKU 级乐观锁 version 字段BundleVariant组合项联合锁分布式事务协调器第四章工具链适配与工程化落地要点4.1 编译器与 IDE 支持现状Java 25 javac、IntelliJ、Eclipse 对 permits 跨文件解析的兼容性验证javac 25.0.1 的跨文件 permits 解析能力// Animal.java sealed interface Animal permits Dog, Cat { } // Dog.java final class Dog implements Animal { } // ✅ 编译通过javac 25.0.1 已完整支持跨源文件的 permits 关系校验要求所有 permitted 子类必须在编译期可见classpath 或模块路径中否则报错error: class Dog is not allowed to extend sealed interface Animal。主流 IDE 兼容性对比工具跨文件 permits 语义高亮实时错误提示重构感知IntelliJ IDEA 2025.1✅✅毫秒级✅重命名自动同步 permits 列表Eclipse JDT 4.35⚠️需手动刷新✅❌不更新 permits 子句4.2 Lombok 与 MapStruct 的适配策略如何安全绕过 sealed 类型的构造器限制问题根源Java 17 的sealed类强制要求所有子类显式声明并禁止反射或 Lombok 自动生成无参构造器而 MapStruct 默认依赖无参构造 setter 进行映射。适配方案使用Builder替代Data配合builderMethodName控制构建入口在 MapStruct 映射器中启用builder Builder.Builder配置Sealed public abstract class Product permits Book, Electronics {} Value Builder public final class Book extends Product { String title; }该写法规避了 sealed 类对默认构造器的封锁Builder生成静态工厂方法MapStruct 可通过Book.builder().title(...).build()安全实例化。参数title直接注入不可变字段无需 setter。映射器配置示例配置项值builderBuilder(builderMethodName builder)componentModelspring4.3 单元测试与契约验证使用 JUnit 5 ParameterizedTest 驱动所有 permitted 子类型的全覆盖断言契约驱动的测试设计当 sealed class 定义了permitted子类型时测试应显式覆盖每个子类以验证行为契约一致性。JUnit 5 的ParameterizedTest天然契合这一需求。参数化测试实现ParameterizedTest MethodSource(allPermittedSubtypes) void testBehaviorContract(Shape shape) { assertNotNull(shape.area()); // 所有子类型必须提供非空面积 } static StreamShape allPermittedSubtypes() { return Stream.of(new Circle(5.0), new Rectangle(3.0, 4.0), new Triangle(3.0, 4.0, 5.0)); }该测试用例通过枚举全部permitted子类型实例强制校验统一接口契约如area()避免新增子类时遗漏测试。覆盖率保障机制子类型是否覆盖验证点Circle✓πr² 计算精度Rectangle✓长×宽边界值4.4 Spring Boot 场景集成ConfigurationProperties 绑定 sealed record sealed interface 的反射增强方案核心限制与增强动机Spring Boot 3.2 原生支持 Java 17 sealed 类型但默认 ConfigurationProperties 绑定器因反射限制无法实例化 sealed record。需通过 ConfigurationPropertiesBindConstructorProvider 扩展绑定流程。增强型绑定配置示例public sealed interface DataSourceConfig permits PooledDataSourceConfig, SimpleDataSourceConfig {} public final record PooledDataSourceConfig( NotBlank String url, int maxPoolSize ) implements DataSourceConfig {}该结构强制类型安全与可扩展性permits 明确允许的实现类避免非法子类注入。反射增强关键步骤注册自定义BindConstructorProvider实现覆盖getBindConstructor方法利用Lookup.findConstructor绕过 sealed 访问检查需setAccessible(true)权限在ConfigurationPropertiesBinder初始化阶段注入增强策略第五章未来展望密封性与模式匹配的下一代领域语言雏形密封类型驱动的领域建模现代领域特定语言DSL正从开放继承转向密封变体sealed variants以强制穷尽式模式匹配。Rust 的 enum、Kotlin 的 sealed class 和 Scala 3 的 enum 均已提供编译期验证能力确保所有业务状态被显式覆盖。模式匹配在金融规则引擎中的落地某跨境支付风控系统将交易状态建模为密封枚举结合模式匹配实现零运行时分支遗漏sealed trait PaymentStatus case object Pending extends PaymentStatus case class Rejected(reason: String) extends PaymentStatus case class Approved(amount: BigDecimal, currency: String) extends PaymentStatus def handle(status: PaymentStatus): Action status match { case Pending initiate3DS() case Rejected(r) logFailure(r); notifyCompliance() case Approved(a, c) dispatchSettlement(a, c) }语言设计权衡对比特性RustScala 3Swift 5.9密封性声明语法enum默认密封enumsealed修饰符enumfrozen非完全等价模式匹配完备性检查✅ 编译器强制✅ 支持match穷尽性分析⚠️ 仅限switchunknown default警告可扩展密封协议的实践路径定义核心密封接口如PaymentEvent禁止外部模块新增子类型通过模块内internal或package-private构造器控制实例化边界配合 ADT 序列化库如 Circe、Serde生成类型安全 JSON Schema
Java 25密封类终于“活”了：如何用sealed interface + permits重构领域模型？
发布时间：2026/5/17 11:40:23
第一章Java 25密封类的演进与本质突破Java 25 将密封类Sealed Classes从预览特性正式转为标准语言特性并在语义表达力、编译期约束强度和运行时反射支持三方面实现质的飞跃。相比 Java 17 引入时的初步形态Java 25 的密封类不再仅依赖sealed、permits关键字进行静态声明而是通过 JVM 层级的ACC_SEALED标志与增强的Class.getPermittedSubclasses()API确保类型封闭性在加载、链接与反射各阶段均不可绕过。核心语法强化Java 25 允许在接口、记录record和普通类上直接声明密封性且子类型可跨模块声明——只需模块描述符中显式导出并使用opens或exports配合to子句public sealed interface Shape permits Circle, Rectangle, Triangle { } // 同一模块内 public final class Circle implements Shape { /* ... */ } // 跨模块子类需在 module-info.java 中声明 // opens com.example.shape to com.example.extended;编译期与运行时保障对比保障维度Java 17预览Java 25正式非法继承检测时机仅编译期报错编译期 类加载期双重拒绝反射获取许可子类getPermittedSubclasses()返回 null若未启用预览始终返回非空Class[]含完整泛型信息典型误用场景与修复遗漏permits列表导致编译失败必须显式列出所有直接子类型不可省略子类未声明final、sealed或non-sealed修饰符JVM 将拒绝加载该类模块间许可未正确声明需在父类所在模块的module-info.java中添加opens pkg to target.module;第二章sealed interface 的语义重构与建模能力跃迁2.1 密封接口作为领域契约从抽象类到接口的范式迁移当领域模型需强制约束实现边界时密封接口sealed interface替代抽象类成为更精准的契约表达方式——它既保留多态性又杜绝意外继承。契约表达力对比特性抽象类密封接口实例化限制不可直接实例化不可实现/扩展除非在声明模块内领域语义“是一个”is-a“属于一组有限变体”one-ofGo 中的等效建模通过接口私有类型type PaymentMethod interface { Kind() string } type creditCard struct{} // unexported type cryptoWallet struct{} // unexported func (creditCard) Kind() string { return credit_card } func (cryptoWallet) Kind() string { return crypto_wallet } // 外部包无法定义新实现形成事实密封该模式通过包级作用域控制实现可见性仅当前包可构造具体类型外部仅能使用接口从而模拟密封语义。Kind() 方法提供运行时类型识别能力支撑领域路由逻辑。2.2 permits 子句的精确控制力编译期约束 vs 运行时开放性权衡编译期强制契约permits 明确限定密封类sealed class的直接子类集合由编译器静态验证public sealed interface Shape permits Circle, Rectangle, Triangle { }该声明禁止任何未在 permits 中列出的类继承 Shape且所有许可子类必须显式声明 permits Shape 或使用 final/sealed/non-sealed 修饰符。运行时灵活性保留尽管编译期严格JVM 层面仍允许动态代理与反射绕过部分限制需 RuntimePermission(accessDeclaredMembers)维度编译期运行时子类合法性强制检查不校验字节码来源实例化控制无直接影响依赖构造器访问权限2.3 与 record、enum、non-sealed 的协同建模构建可验证的类型图谱类型契约的分层表达record 定义不可变数据骨架enum 刻画有限状态空间non-sealed 显式开放扩展边界——三者组合形成可静态校验的类型图谱。public non-sealed interface PaymentEvent {} // 允许跨模块实现 public record OrderPlaced(String orderId, BigDecimal amount) implements PaymentEvent {} public enum PaymentStatus { PENDING, CONFIRMED, FAILED }该声明确立了事件载体OrderPlaced与状态维度PaymentStatus的正交性编译器可验证所有 PaymentEvent 子类型是否覆盖业务语义全集。可验证性保障机制特性验证能力协同效果record字段完整性与不可变性确保事件载荷无歧义enum状态值穷举性杜绝非法状态字面量2.4 模块化边界下的 permits 可见性规则跨模块密封关系的声明与验证permits 语义本质permits 并非访问修饰符而是模块系统对密封类sealed class跨模块继承的显式授权契约。它将“谁可扩展”从运行时检查前移至编译期模块图验证。跨模块声明示例// module-a/src/main/java/com/example/shape/Shape.java package com.example.shape; public sealed interface Shape permits Circle, Rectangle {}该声明本身不暴露实现类Circle 和 Rectangle 必须在同一模块或被 permits 显式授权的其他模块中声明并通过 requires transitive 传递可访问性。模块描述符约束模块声明是否合法原因module module.a { exports com.example.shape; }否未声明opens或uses密封类型无法被外部模块继承module module.b { requires transitive module.a; }是仅当module.a同时opens com.example.shape to module.b时才允许实现2.5 密封接口的反模式识别何时不该用 sealed interface——基于DDD聚合根与值对象的实证分析聚合根的演化性冲突当聚合根需支持跨版本事件溯源或运行时动态行为注入如插件化策略sealed interface会阻碍合法扩展。Kotlin 示例sealed interface OrderStatus { data object Created : OrderStatus() data object Confirmed : OrderStatus() }该定义禁止外部模块添加PaidViaCrypto等新状态违反聚合根“随业务演进”的DDD原则。值对象的不可变性误用值对象应天然可扩展如新增货币精度策略但密封接口强制穷举封闭类型系统阻断领域方言适配如区域化金额格式编译期校验替代了运行时语义验证增加测试负担适用边界对照表场景适合 sealed interface应避免 sealed interface状态机有限、稳定、无外部扩展需求需支持插件/多租户定制值对象纯数据建模且无业务逻辑扩展点含计算策略或格式化变体第三章领域模型重构实战以电商订单域为例3.1 订单状态机的密封建模State 接口 具体状态实现的不可扩展性保障核心设计意图通过接口抽象与具体类型封闭杜绝非法状态注入和运行时意外分支确保状态流转仅限于预定义集合。Go 语言实现示例// State 定义唯一行为契约 type State interface { Handle(ctx context.Context, order *Order) error } // 具体状态类型全部为 unexported struct禁止外部构造 type pendingState struct{} type shippedState struct{} type cancelledState struct{} var ( PendingState State pendingState{} ShippedState State shippedState{} CancelledState State cancelledState{} )该模式利用 Go 的包级可见性小写首字母结构体 包内预实例化变量使外部无法 new 任意状态强制状态演进路径可控。状态迁移约束对比方式可扩展性安全性开放接口 外部实现高但危险低易引入非法状态密封接口 包内枚举零受控高编译期锁定3.2 支付策略的领域隔离PaymentMethod sealed interface 与风控策略注入的解耦设计领域边界显式化通过 Kotlin 的sealed interface定义支付方式契约强制所有实现类归属同一受限继承体系天然支持 exhaustive when 表达式杜绝运行时类型遗漏。sealed interface PaymentMethod { val code: String val displayName: String }code用于路由匹配如 alipaydisplayName供前端展示接口不可被外部模块随意实现保障领域内聚性。风控策略动态装配采用构造函数参数注入风控策略而非硬编码或 Service Locator 模式每个PaymentMethod实现仅依赖抽象RiskEvaluator策略实例由 DI 容器按上下文如商户等级、交易金额绑定策略组合能力对比方案编译期安全策略热替换测试隔离性if-else 分支❌❌❌Sealed 策略注入✅✅✅3.3 商品变体建模ProductVariant 密封族在 SKU 多态性与库存一致性间的平衡在电商系统中ProductVariant作为密封族sealed family通过编译期约束确保所有变体类型显式声明避免运行时类型逸出。核心类型定义sealed interface ProductVariant { val sku: String val stock: Int } data class ColorSizeVariant( override val sku: String, override val stock: Int, val color: String, val size: String ) : ProductVariant data class BundleVariant( override val sku: String, override val stock: Int, val includedItems: ListString ) : ProductVariant密封族强制穷尽匹配使when表达式可静态验证覆盖全部子类型保障库存更新逻辑不遗漏任一变体形态。库存一致性保障机制变体类型库存粒度并发控制策略ColorSizeVariantSKU 级乐观锁 version 字段BundleVariant组合项联合锁分布式事务协调器第四章工具链适配与工程化落地要点4.1 编译器与 IDE 支持现状Java 25 javac、IntelliJ、Eclipse 对 permits 跨文件解析的兼容性验证javac 25.0.1 的跨文件 permits 解析能力// Animal.java sealed interface Animal permits Dog, Cat { } // Dog.java final class Dog implements Animal { } // ✅ 编译通过javac 25.0.1 已完整支持跨源文件的 permits 关系校验要求所有 permitted 子类必须在编译期可见classpath 或模块路径中否则报错error: class Dog is not allowed to extend sealed interface Animal。主流 IDE 兼容性对比工具跨文件 permits 语义高亮实时错误提示重构感知IntelliJ IDEA 2025.1✅✅毫秒级✅重命名自动同步 permits 列表Eclipse JDT 4.35⚠️需手动刷新✅❌不更新 permits 子句4.2 Lombok 与 MapStruct 的适配策略如何安全绕过 sealed 类型的构造器限制问题根源Java 17 的sealed类强制要求所有子类显式声明并禁止反射或 Lombok 自动生成无参构造器而 MapStruct 默认依赖无参构造 setter 进行映射。适配方案使用Builder替代Data配合builderMethodName控制构建入口在 MapStruct 映射器中启用builder Builder.Builder配置Sealed public abstract class Product permits Book, Electronics {} Value Builder public final class Book extends Product { String title; }该写法规避了 sealed 类对默认构造器的封锁Builder生成静态工厂方法MapStruct 可通过Book.builder().title(...).build()安全实例化。参数title直接注入不可变字段无需 setter。映射器配置示例配置项值builderBuilder(builderMethodName builder)componentModelspring4.3 单元测试与契约验证使用 JUnit 5 ParameterizedTest 驱动所有 permitted 子类型的全覆盖断言契约驱动的测试设计当 sealed class 定义了permitted子类型时测试应显式覆盖每个子类以验证行为契约一致性。JUnit 5 的ParameterizedTest天然契合这一需求。参数化测试实现ParameterizedTest MethodSource(allPermittedSubtypes) void testBehaviorContract(Shape shape) { assertNotNull(shape.area()); // 所有子类型必须提供非空面积 } static StreamShape allPermittedSubtypes() { return Stream.of(new Circle(5.0), new Rectangle(3.0, 4.0), new Triangle(3.0, 4.0, 5.0)); }该测试用例通过枚举全部permitted子类型实例强制校验统一接口契约如area()避免新增子类时遗漏测试。覆盖率保障机制子类型是否覆盖验证点Circle✓πr² 计算精度Rectangle✓长×宽边界值4.4 Spring Boot 场景集成ConfigurationProperties 绑定 sealed record sealed interface 的反射增强方案核心限制与增强动机Spring Boot 3.2 原生支持 Java 17 sealed 类型但默认 ConfigurationProperties 绑定器因反射限制无法实例化 sealed record。需通过 ConfigurationPropertiesBindConstructorProvider 扩展绑定流程。增强型绑定配置示例public sealed interface DataSourceConfig permits PooledDataSourceConfig, SimpleDataSourceConfig {} public final record PooledDataSourceConfig( NotBlank String url, int maxPoolSize ) implements DataSourceConfig {}该结构强制类型安全与可扩展性permits 明确允许的实现类避免非法子类注入。反射增强关键步骤注册自定义BindConstructorProvider实现覆盖getBindConstructor方法利用Lookup.findConstructor绕过 sealed 访问检查需setAccessible(true)权限在ConfigurationPropertiesBinder初始化阶段注入增强策略第五章未来展望密封性与模式匹配的下一代领域语言雏形密封类型驱动的领域建模现代领域特定语言DSL正从开放继承转向密封变体sealed variants以强制穷尽式模式匹配。Rust 的 enum、Kotlin 的 sealed class 和 Scala 3 的 enum 均已提供编译期验证能力确保所有业务状态被显式覆盖。模式匹配在金融规则引擎中的落地某跨境支付风控系统将交易状态建模为密封枚举结合模式匹配实现零运行时分支遗漏sealed trait PaymentStatus case object Pending extends PaymentStatus case class Rejected(reason: String) extends PaymentStatus case class Approved(amount: BigDecimal, currency: String) extends PaymentStatus def handle(status: PaymentStatus): Action status match { case Pending initiate3DS() case Rejected(r) logFailure(r); notifyCompliance() case Approved(a, c) dispatchSettlement(a, c) }语言设计权衡对比特性RustScala 3Swift 5.9密封性声明语法enum默认密封enumsealed修饰符enumfrozen非完全等价模式匹配完备性检查✅ 编译器强制✅ 支持match穷尽性分析⚠️ 仅限switchunknown default警告可扩展密封协议的实践路径定义核心密封接口如PaymentEvent禁止外部模块新增子类型通过模块内internal或package-private构造器控制实例化边界配合 ADT 序列化库如 Circe、Serde生成类型安全 JSON Schema
