接口多态是微服务支付插件解耦的核心手段——通过定义面向业务的统一支付契约（如process/ refund方法、业务语义DTO与异常），各渠道独立实现且仅依赖接口，结合配置驱动的IoC动态注入，实现渠道增删、灰度切换零代码改动。
接口多态是微服务支付插件解耦的核心手段——它让订单服务完全不感知微信、支付宝或PayPal的存在，只认一个能力契约，渠道增删、灰度切换、环境隔离全靠配置驱动，业务代码零改动。
定义面向业务的支付接口契约
接口不是对已有实现的总结，而是从调用方视角提炼的最小能力约定。比如：
- 用ChargeRequest和ChargeResult封装入参与返回，字段全是业务语言（payeeAccount、currency），不暴露三方字段或技术细节
- 方法签名干净：只保留
process(ChargeRequest req)和refund(RefundRequest req)，不加@RequestBody、@Valid等框架注解 - 异常统一为业务语义异常，如
PaymentFailedException，屏蔽底层API异常（AlipayApiException等）
实现类按渠道独立开发、独立部署
每个支付渠道写一个实现类，彼此无依赖、无继承、无共享状态：
-
WechatPayment专注对接微信开放平台，处理prepay_id、签名、回调验签 -
PayPalAdapter封装REST API调用、token刷新、国际货币转换 - 所有实现类只
implements PaymentProcessor，不继承任何父类，避免抽象类引入隐式耦合
运行时通过IoC容器动态注入对应实现
不硬编码new，也不用ServiceLoader或ApplicationContext.getBean()隐式查找：
立即学习“Java免费学习笔记（深入）”；
- Spring中用
@ConditionalOnProperty(name = "payment.channel", havingValue = "wechat")激活微信Bean - 测试环境注入
MockPaymentProcessor，沙箱环境用SandboxAlipay，生产走真实网关 - 配合Nacos或Apollo配置中心，运行时修改
payment.channel=paypal即可切流，无需重启服务
分层边界清晰，各层只认接口不认实现
支付插件解耦不是单点优化，而是贯穿整个调用链：
- Controller层接收DTO，转成
ChargeRequest后交给Service，不碰任何支付实现 - Service层持有
PaymentProcessor接口引用，通过构造器注入，单元测试可直接传入mock对象 - DAO层同理——
UserRepository接口下可自由切换MySQL/Redis实现，订单服务完全无感
不复杂但容易忽略：解耦成败不在有没有接口，而在是否守住“只依赖契约、不感知实现”这一条线。渠道变了，改的只是配置和一个新类；系统升级了，老支付逻辑照常跑，新渠道并行验证——这才是多态在微服务里该有的样子。
