工厂模式与策略模式结合实现支付网关解耦：策略接口统一行为契约，工厂负责注册、动态开关与缓存策略实例，业务层仅依赖抽象上下文，支持多层级渠道扩展。
工厂模式和策略模式结合，核心是让支付网关既不硬编码渠道选择逻辑，也不直接耦合具体支付实现——前者管“怎么造”，后者管“怎么用”，二者配合就能做到新增渠道零修改主流程。
支付策略接口统一行为契约
先定义一个清晰、稳定的支付策略接口，覆盖所有渠道共性操作，比如支付、退款、查询、回调处理：
- 接口方法名、参数结构、返回类型必须一致，避免像早期代码中支付宝用 pay()、微信用 executePayment() 这类不统一命名
- 建议包含扩展点，例如 supportRefund() 布尔判断，因为部分渠道（如某些H5扫码）可能不支持主动退款
- 每个具体支付类（AlipayStrategy、WxPayStrategy、UnionPayStrategy）只专注自身SDK调用和协议转换，不感知其他渠道
工厂负责策略对象的创建与分发
工厂不是简单 if-else new 对象，而是承担注册、缓存、校验三重职责：
- 启动时自动扫描并注册所有 @Service 标注的策略实现类（Spring Boot 场景下可配合 ApplicationContext 获取 Bean）
- 支持从配置中心动态加载渠道开关，比如 payment.channel.wechat.enabled=false，关闭后工厂直接拒绝返回该策略
- 内部用 ConcurrentHashMap 缓存已创建实例，避免每次请求都 new 对象；对需要初始化参数（如商户私钥、网关地址）的策略，工厂在首次获取时完成完整构建
上下文解耦调用方与具体实现
业务层（如 OrderService）不再写任何渠道判断，只依赖抽象上下文：
- 接收请求中的 channel 字段（如 "alipay_app"、"wechat_jsapi"），交给工厂获取对应策略
- 调用统一的 pay(request) 方法，结果类型固定为 PaymentResult，字段含义标准化（如 status=SUCCESS/PROCESSING/FAILED）
- 异常统一包装，比如 UnsupportedChannelException 由工厂抛出，业务层只需捕获一层，无需分散在多处 try-catch
应对多层级渠道结构的扩展设计
当单个供应商提供多种接入方式（如微信有 JSAPI、APP、小程序、H5），可叠加抽象工厂：
- 第一层工厂按供应商划分：WechatFactory、AlipayFactory、UnionPayFactory
- 第二层工厂按场景细分：WxJsapiStrategy、WxAppStrategy、WxMiniProgramStrategy，均由 WechatFactory 统一管理
- 请求参数中带二级标识（如 channel=wechat&subType=jsapi），主工厂路由到供应商工厂，再由其子工厂匹配具体策略
