密封类用于模块内状态建模，通过编译期约束杜绝非法子类、保障switch穷尽性、禁止跨模块继承，并结合record实现不可变状态载体。
密封类（sealed）不是为微服务间通信设计的，而是用于**模块内类型建模**的编译期约束机制。它无法隔离服务边界、不参与网络调用、也不影响运行时部署结构。但正因如此，它能在微服务**内部核心组件的状态建模阶段**，从源头切断“不可控子类化”带来的多态风险——比如状态枚举膨胀、非法状态注入、switch 分支遗漏、序列化歧义等。
用密封类定义有限且可穷尽的核心状态类型
微服务中常见的状态载体（如订单状态、支付结果、任务执行反馈）若用普通抽象类或接口开放继承，极易被随意新增子类，导致：
- 业务逻辑分支散落在各处，难以统一维护
- 反序列化时遇到未知子类抛出
ClassNotFoundException或静默失败 - 使用
instanceof判断时漏覆盖新类型，引发逻辑空转
改用密封抽象类，强制收口所有合法状态：
public sealed abstract class PaymentResult permits Success, Failure, Pending { }
再配合 final 子类承载具体语义与数据：
public final class Success extends PaymentResult { public final String txId; public Success(String txId) { this.txId = txId; } }
这样，任何新增状态都必须显式修改 permits 列表并添加对应子类——既是代码审查点，也是架构演进的显性信号。
与模式匹配结合，实现编译期穷尽性保障
在处理核心状态流转逻辑（如状态机驱动、事件响应、API 响应组装）时，用 switch 表达式替代 if-else 或 instanceof 链：
String toResponse(PaymentResult result) {
return switch (result) {
case Success s -> "OK: " + s.txId;
case Failure f -> "ERR: " + f.reason;
case Pending p -> "WAITING";
};
}
编译器会检查是否覆盖全部 permits 子类。一旦有人新增 Refunded 但忘了更新 switch，编译直接失败——把运行时隐患拦截在构建阶段。
禁止跨模块继承，确保封装边界清晰
Java 密封类要求所有 permits 子类与父类**位于同一模块**（或默认模块下同一包）。这意味着：
- 外部模块（如其他微服务 Jar、插件包）无法声明新子类，杜绝了“黑盒扩展”破坏状态契约
- 即使通过反射绕过访问控制，也无法通过编译，更难集成进主流程
- 模块化封装 + 密封约束，双重加固核心状态的完整性
这对微服务中需强一致性的领域模型（如金融交易凭证、合规审计事件）尤为关键。
搭配记录类（Record）与不可变性，消除状态污染风险
密封类常与 record 联用，天然支持不可变数据建模：
public final class Failure extends PaymentResult {
public final String reason;
public final int errorCode;
public Failure(String reason, int errorCode) {
this.reason = reason;
this.errorCode = errorCode;
}
}
或者直接写成 record：
public record Failure(String reason, int errorCode) extends PaymentResult { }
不可变性 + 明确子类集合 + 编译期校验，三者叠加，使状态对象成为可信的数据载体，避免因子类重写方法、篡改字段而引发的多态副作用。
