如何在ThinkPHP中使用策略模式重构支付方式_多通道支付网关的工厂类封装-ThinkPHP-PHP中文网

thinkphp中支付策略模式需定义paymentstrategy接口及alipaystrategy等实现类，通过paymentfactory按channel动态实例化，控制器仅负责参数校验与异常分类处理，策略类应无状态、依赖注入、不耦合框架组件。

如何在thinkphp中使用策略模式重构支付方式_多通道支付网关的工厂类封装

策略模式在 ThinkPHP 里不是靠框架内置功能，而是靠你定义好接口、让不同支付方式（如 AlipayStrategy、WechatPayStrategy）去实现它。关键不是“用框架”，而是“让控制器不关心具体支付逻辑”。

常见错误是把所有支付逻辑塞进一个方法里，加一堆 if-else 判断渠道，后续加新渠道就得改老代码，一动就崩。

工厂类本质就是一个“根据字符串返回对象”的函数，不是魔法。ThinkPHP 没规定必须叫 PaymentFactory，但名字要能一眼看出职责。

典型翻车点：硬编码判断、new 出来不检查类是否存在、没做策略合法性校验，导致传个 channel=bitcoin 就抛 Class not found 错误。

工厂方法接收 $channel（如 'alipay'、'wechat'），转成 PascalCase 后拼路径：app\common\strategy\payment\AlipayStrategy
用 class_exists() 检查类是否存在，不存在就抛出明确异常：InvalidArgumentException("Unsupported payment channel: {$channel}")
不要用 Loader::import() 或手动 require —— ThinkPHP 6+ 自动加载已覆盖命名空间，确保类文件名和类名严格一致
如果需要传参（如商户配置），工厂应接受配置数组并透传给策略构造函数，而不是在工厂里读取配置文件

控制器只该做三件事：收参数、交差给策略、处理返回。它不该知道支付宝用的是 RSA 还是公钥，也不该拼接 notify URL。

最容易被忽略的是异常处理粒度——有人把整个 $strategy->pay() 包进一个 try-catch，结果网络超时和签名错误都返回“支付失败”，前端没法区分重试还是改参数。

从请求中提取 $channel = input('channel')，立刻交给工厂：$strategy = PaymentFactory::make($channel)
调用前校验必要参数：input('amount')、input('order_no') 是否为空，不满足直接返回 400
策略方法返回应是标准数组，包含 status（true/false）、data（支付跳转链接或预下单 ID）、message（仅用于日志，不直接返回给前端）
捕获策略抛出的特定异常，比如 InvalidSignException 返回 401，NetworkTimeoutException 返回 503，让前端决定是否重试

可以注册，但没必要，还容易埋坑。策略类是无状态、按需创建的，不是全局单例。

有人图省事，在 app/provider.php 里 bind PaymentStrategy::class 到某个实现，结果发现换渠道时容器根本不会重新解析——它只认接口，不认运行时参数。

服务容器适合管理「生命周期长、可复用、有共享状态」的对象（如数据库连接、Redis 实例），策略类不符合
若强行绑定，就必须为每个渠道单独 bind 一次（bind('alipay.strategy', AlipayStrategy::class)），失去工厂的灵活性
更隐蔽的问题：TP 的容器在 CLI 模式下可能缓存绑定关系，导致队列任务里拿到过期策略实例
真正该进容器的是工厂本身（PaymentFactory::class），其他都让它按需 new

策略模式的复杂点不在写几个类，而在于边界划分——哪些该由策略决定（比如签名生成方式），哪些必须由上层控制（比如幂等 key 生成、异步通知验签后的事务处理）。漏掉任何一个边界，重构就变成换汤不换药。