Java sealed interface组织支付状态类型的建模方式

支付状态通常不是几个可以随意组合的布尔值：一笔订单既不能同时“已支付又待支付”，也不应该让任意模块偷偷增加一个处理器分支。Java 的 sealed interface 适合把这组状态建模成封闭层次，配合 switch 表达式后，状态集合变化会更早暴露在编译期。

把支付状态拆成一个 sealed 根接口和若干 final/record 实现，用 permits 明确允许的集合；处理器覆盖这些类型后，新增状态会提醒你同步修改分发逻辑。

下面以 Java 21+ 的模式 switch 为例。sealed 类型本身在 Java 17 已正式可用，而类型模式 switch 在 Java 21 才适合按本文写法落地。

先把支付状态的边界写进类型

状态根接口只放所有状态都需要的稳定信息，例如订单号。permits 是建模的关键：它不是文档注释，而是编译器可见的直接实现名单。示例把待支付、已支付、已失败和已取消分成四种互斥状态。

// sealed 根接口限制支付状态的直接实现集合
public sealed interface PaymentState
        permits Pending, Paid, Failed, Cancelled {
    // 所有状态都保留订单号，便于日志和幂等处理
    String orderId();
}

// record 默认是 final，适合承载不可变状态数据
public record Pending(String orderId) implements PaymentState {}

public record Paid(String orderId, String transactionId)
        implements PaymentState {}

public record Failed(String orderId, String reason)
        implements PaymentState {}

public record Cancelled(String orderId, String operator)
        implements PaymentState {}

这里没有额外的 isPaid、isFailed 标志位。一个对象只能落在明确的状态类型中，支付流水号、失败原因和取消人也跟着状态走，调用方不必猜哪些字段在当前状态下有效。

用 switch 表达式集中分发状态

当支付状态需要映射成对账动作、通知动作或页面提示时，把分发集中到一个处理器里更容易维护。Java 21+ 可以直接使用类型模式；四个允许的类型都出现后，不需要为了“保险”再放一个无意义的 default。

public final class PaymentRouter {
    public static String describe(PaymentState state) {
        // switch 表达式统一返回结果，避免分支遗漏返回值
        return switch (state) {
            case Pending p -> "等待支付：" + p.orderId();
            case Paid p -> "已入账：" + p.transactionId();
            case Failed f -> "支付失败：" + f.reason();
            case Cancelled c -> "已取消：" + c.operator();
        };
    }
}

如果以后增加 Refunded 并把它加入 permits，这个 switch 就会因为没有覆盖新类型而提醒维护者。这个反馈比线上出现一个静默的默认分支更有价值。

新增状态时的处理边界

新增状态要同时改三处：状态实现、permits 列表和所有依赖穷举处理的 switch。不要为了快速通过编译直接加 default，否则新状态可能被当成未知状态吞掉；只有确实需要兼容外部扩展或保留未知值时，才应把默认策略写成明确的监控、拒绝或人工复核动作。

还要区分版本边界：Java 17 可以使用 sealed interface 和 record，但本文这种类型模式 switch 应按 Java 21+ 配置编译。若项目必须停留在 Java 17，可以保留 sealed 状态层次，再使用 instanceof 分支，并把“未覆盖状态”的检查交给测试或显式异常。

输入为 null 时，穷举状态并不等于自动处理空值。支付入口应在构造状态或进入路由前拒绝空值，或者在 switch 中显式处理 case null，不要让空引用把类型边界变成隐含的运行时故障。

落地前的速查清单

最终目标不是为了使用一个新语法，而是让支付状态的业务边界成为可读、可检查的类型契约。状态集合小而稳定时，sealed interface 能减少非法组合；状态需要由第三方持续扩展时，则应回到普通接口加注册机制，不要强行封闭。

相关问题

sealed interface 和 enum 该怎么选？

只有固定名称、没有不同数据结构时，enum 更直接；每种状态需要不同字段或行为时，sealed interface 加 record 更灵活。

为什么不建议总写 default？

default 会让新增状态绕过编译期提醒。支付、对账这类不能静默忽略的业务，显式覆盖通常更安全。