Java sealed interface 做支付渠道路由：和 enum + switch 怎么选

支付渠道从微信、支付宝扩展到银行卡和企业钱包后，最先变乱的通常不是对外调用接口，而是“渠道对应的差异化逻辑到底该放哪层维护”。一种写法把所有渠道类型定义塞进 enum，再用多个 switch 分散处理分支逻辑；另一种写法用 Java sealed interface 把允许的渠道实现收紧到一个明确边界。两种方案都能跑通上线，核心取舍点在于渠道集合是否稳定、各渠道行为差异多大，以及团队是否接受用 Java 17 的类型系统做边界约束。

先把支付渠道的变化范围说清楚

假设订单服务收到 PayCommand，里面只有订单号、金额和渠道标识字段。真正执行发起支付操作时，微信需要 appId，银行卡渠道要额外传收单机构号，企业钱包还要带租户专属标识。它们都共享“发起支付”这个动作，但参数校验、签名逻辑和结果解析规则并不通用。

这里没必要盲目追求更“新潮”的写法。如果渠道只有两三个，每个渠道的差异仅仅对应一个配置值，枚举反而更容易让刚接手项目的同事读懂。sealed interface 的价值，只有在类型本身要携带专属行为、定制规则和测试替身的时候才会体现出来。

用 enum + switch 写出最小可用版本

先看最容易落地的轻量方案。PaymentChannel 只用来描述渠道名称标识，路由层集中决定调用哪个对应的客户端处理：

enum PaymentChannel {
    WECHAT,
    ALIPAY,
    BANK
}

record PayCommand(String orderId, long amountFen, PaymentChannel channel) {}

final class PaymentRouter {
    PaymentResult pay(PayCommand command) {
        return switch (command.channel()) {
            case WECHAT -> wechatPay(command);
            case ALIPAY -> alipayPay(command);
            case BANK -> bankPay(command);
        };
    }

    private PaymentResult wechatPay(PayCommand command) {
        return PaymentResult.accepted("wechat");
    }

    private PaymentResult alipayPay(PayCommand command) {
        return PaymentResult.accepted("alipay");
    }

    private PaymentResult bankPay(PayCommand command) {
        return PaymentResult.accepted("bank");
    }
}

record PaymentResult(String channel, boolean accepted) {
    static PaymentResult accepted(String channel) {
        return new PaymentResult(channel, true);
    }
    static PaymentResult rejected(String reason) {
        return new PaymentResult(reason, false);
    }
}

这个版本的优点是逻辑集中、全文可搜索、改动影响面小。Java 编译器会主动提醒你有没有遗漏的枚举分支，非常适合所有渠道逻辑都收敛在同一个应用内迭代的场景。但它的短板也很明显：随着渠道规则越来越多，PaymentRouter 会同时承担参数拼装、签名生成、外部调用和结果转换多份逻辑，后期单元测试很快就变成单个大类的多分支覆盖任务。

让渠道实现自己管理专属逻辑

如果每个渠道都需要维护大量独立规则，可以让路由层只依赖一个封闭的顶层接口。Java 17 的 sealed interface 配合 permits，可以直接把允许的全部实现写在类型声明的旁边，边界一眼就能看全：

sealed interface PaymentMethod
        permits WechatMethod, AlipayMethod, BankMethod {
    String channel();
    PaymentResult pay(PayCommand command);
}

record WechatMethod(String appId) implements PaymentMethod {
    public String channel() {
        return "wechat";
    }

    public PaymentResult pay(PayCommand command) {
        if (command.amountFen() 

路由器本身只负责处理通用的公共边界逻辑，比如订单号非空校验、金额溢出拦截、幂等键生成这些通用能力；渠道实现类自行处理自己的请求对象构造和返回结果解析。这么做不是为了少写几行重复代码，而是把“哪段规则该由哪个对象持有”放到代码结构里更合理的位置。

sealed interface 的编译期边界能覆盖到哪里

你完全可以把支付相关的入参建模为密封类型，然后在上层统一做分支处理：

static PaymentResult route(PaymentMethod method, PayCommand command) {
    if (command.orderId() == null || command.orderId().isBlank()) {
        return PaymentResult.rejected("missing_order");
    }
    return switch (method) {
        case WechatMethod value -> value.pay(command);
        case AlipayMethod value -> value.pay(command);
        case BankMethod value -> value.pay(command);
    };
}

当团队新增 WalletMethod 并把它的实现声明加入 permits 后，所有依赖这个类型做分支判断的代码都会触发重新检查。遗漏分支不再是代码评审时才能发现的小问题，而是直接变成编译阶段就会抛出来的错误。这个特性对支付、风控、订单状态这类本身就是有限状态的业务域非常实用。

但它没法替代必要的运行时校验。反序列化请求拿到的入参里，仍可能出现不存在的渠道字符串，外部支付网关也可能返回系统没收录过的状态值。边界层仍然要单独处理字符串映射失败、金额单位错误和重复请求这类异常场景。

测试时不要把类型穷尽当成业务逻辑全覆盖

不管选哪种设计方案，完整的业务测试都不能省。sealed interface 只能保证实现集合在代码层面完全可见，没法保证每个渠道的签名字段、超时返回和重复回调逻辑都天然正确。

class PaymentRoutingChecks {
    static void checkPositiveAmount() {
        PayCommand command = new PayCommand("order-1001", 1990, null);
        PaymentResult result = PaymentRouter.route(
                new WechatMethod("app-demo"), command);
        if (!result.accepted()) {
            throw new AssertionError("positive amount should pass");
        }
    }

    static void checkMissingOrder() {
        PayCommand command = new PayCommand("", 1990, null);
        PaymentResult result = PaymentRouter.route(
                new WechatMethod("app-demo"), command);
        if (!"missing_order".equals(result.channel())) {
            throw new AssertionError("missing order should be rejected");
        }
    }
}

测试清单至少要覆盖这些场景：每个渠道的必填字段校验、零金额和负金额拦截、同一幂等键重复提交、外部返回结果映射失败，以及退款流程是否复用了对应渠道的规则。接口层的类型覆盖只是第一层防护，支付相关的业务逻辑全覆盖才是你敢直接上线的前提。

按扩展方式做最后选择

更实用的判断方式是看“后续的变化来自哪里”：如果新渠道是靠产品配置就能加的，而且所有渠道都走同一套固定流程驱动，enum + switch 完全够用；如果新增一个渠道就要同步引入新的签名方式、退款协议和限额策略，sealed interface 能让代码的边界拆解得更清晰。

常见问题：Java 支付渠道建模

sealed interface 适合做动态插件系统吗？

不适合。它的强项是提前限制好已知的实现集合，帮编译器做全分支检查；动态插件场景需要用普通 interface、注册机制和版本兼容策略来实现。

enum + switch 一定比 sealed interface 慢吗？

不能这么一概而论。支付链路的主要耗时通常来自网络请求和外部网关处理，建模方式带来的性能差异完全不是决策重点，优先对比维护成本和测试成本才对。

把支付渠道做成 record 会不会丢失安全性？

record 只是提供了更简洁的数据承载方式和基于字段组件的 equals、hashCode 语义，不会自动隐藏敏感字段。打日志、序列化和抛出异常信息的时候，你仍要主动避免输出密钥、签名原文和完整卡号这类敏感数据。

Java 版本低于 17 怎么办？

可以先用普通 interface 加显式的注册表做管理，或者保留 enum + switch 方案。不要为了用 sealed interface 强行升级支付服务的 Java 版本，先完整评估运行环境、构建链路和所有依赖的兼容范围再动手。

支付渠道建模的核心不是在 enum 和 sealed interface 之间争论语法细节，而是把变化范围交给匹配的代码边界。渠道少且行为相似，就让路由保持集中；渠道有限但规则各自独立，就让实现类承载专属行为；如果渠道必须由外部系统动态加入，则选择可注册的普通接口。最后用幂等校验、金额拦截和回调覆盖测试，把类型设计的收益落到真实的交易约束里。