适配器模式通过定义统一PayGateway接口并为微信、支付宝、银联分别实现适配器类，封装各平台请求字段、签名验签、回调处理等差异，使业务层仅依赖抽象接口，提升可维护性与扩展性。
支付接口不统一，直接硬编码会越来越难维护
不同支付平台（微信、支付宝、银联）的请求字段、签名方式、回调验签逻辑、返回结构全都不一样。硬写三套几乎一样的业务逻辑，改一个就要同步修三个地方，出错概率翻倍。适配器模式不是为了炫技，是为把「变」的部分锁死在单独一层，让上层只认一个接口。
核心思路：定义统一的 PayGateway 接口，每个支付渠道写一个实现类，内部封装它自己的 SDK 或 HTTP 请求细节。业务代码只跟 PayGateway 打交道。
- 微信用
WxPayAdapter，把unifiedOrder、notify、verifyNotify等操作转成它要求的 XML/JSON + 签名 - 支付宝用
AlipayAdapter，调它的AlipayTradeService或直连alipay.trade.pay接口，把参数映射过去 - 银联用
UnionpayAdapter，处理它那套tn、cert、signCert的证书签名流程
接口定义必须收窄，别暴露渠道特有参数
如果 PayGateway::pay() 方法允许传 sub_mch_id（微信子商户号）或 store_id（支付宝门店 ID），就等于把渠道耦合泄露到了上层。适配器要负责“翻译”，而不是“转发”。
正确做法是定义最小必要参数集，比如：
立即学习“PHP免费学习笔记（深入）”；
interface PayGateway
{
public function pay(string $orderNo, float $amount, string $subject, string $returnUrl, string $notifyUrl): array;
public function notifyVerify(array $rawInput): bool;
public function query(string $orderNo): array;
}
-
$rawInput是原始$_POST或file_get_contents('php://input')，由适配器自己解析和验签，不依赖框架自动解析 - 返回统一结构：
['success' => true, 'pay_url' => '...', 'trade_no' => '...']，上层不用关心是跳转链接、二维码还是 JSAPI 调起参数 - 微信 JSAPI 支付需要
openid，但不能加到接口里——应该在WxPayAdapter构造时注入，或通过上下文传递
签名和证书处理最容易出错
微信用 MD5/RSA2 + 商户私钥签名；支付宝用 RSA2 + 应用私钥；银联用 SHA256withRSA + 机构证书。这些密钥和证书路径、格式、加载方式各不相同，且不能硬编码进适配器类。
- 统一从配置文件读取路径：
'wx' => ['cert_path' => '/path/to/apiclient_cert.pem', 'key_path' => '/path/to/apiclient_key.pem'] - 微信验签必须用
openssl_pkey_get_public()加载平台公钥，不是商户自己的；支付宝验签要用openssl_get_publickey()加载支付宝公钥字符串 - 银联回调通知里的
signature是 base64 编码，需先base64_decode()再验签，漏这步必失败 - 本地开发测试时，微信沙箱环境要用沙箱密钥，且
unifiedOrder接口地址也要换成沙箱域名
回调入口不能复用路由，必须隔离处理
微信、支付宝、银联的回调 URL 都要求固定且可公网访问，但它们的请求方式（GET/POST）、数据格式（XML/JSON/form）、签名字段位置（URL 参数 / Header / Body）完全不同。试图用一个控制器方法统一接收再分发，很快会变成 if-else 泥潭。
- 每个渠道配独立入口脚本，如
/notify/wx.php、/notify/alipay.php，不走框架路由 - 入口脚本只做三件事：获取原始输入 → 实例化对应适配器 → 调
notifyVerify()→ 返回平台要求的响应（微信要空字符串，支付宝要success） - 别在回调里写业务逻辑（如更新订单状态），只做验签和触发事件；后续逻辑用消息队列或异步任务解耦
- 支付宝回调可能带
charset=utf-8在 header 里，但实际 body 是 GBK，file_get_contents('php://input')读出来就是乱码——得用mb_convert_encoding($raw, 'UTF-8', 'GBK')
最麻烦的从来不是调通一次支付，而是回调验签失败时日志没打全、证书路径写错、时间戳校验过严、或者用了测试环境公钥去验正式环境回调。这些细节藏得深，出问题只能靠原始请求 dump 和逐行比对文档。
