必须将支付通道抽象为可插拔实现，各通道隔离初始化、请求构造、响应解析和回调处理；通过配置驱动动态加载具体实现，避免硬编码耦合与隐式注册。
为什么不能直接在 main 包里硬编码支付接口调用
硬编码会导致支付通道耦合进业务逻辑，一旦某家支付 SDK 升级、停服或需要灰度切换，就得改业务代码、重新编译部署。更麻烦的是，不同通道的错误码含义、重试策略、签名方式、异步通知验签逻辑差异极大，混在一起写极易出错。
关键判断：必须把支付通道抽象为可插拔的实现，且各通道的初始化、请求构造、响应解析、回调处理全部隔离。
-
PayClient接口定义统一方法：Charge(ctx, req *ChargeReq) (*ChargeResp, error)、NotifyVerify(r *http.Request) (string, error)等 - 每个通道（如微信、支付宝、Stripe）各自实现该接口，放在独立子包下，例如
payment/wechat、payment/alipay - 初始化时通过配置驱动加载具体实现，避免
import _ "payment/wechat"这类隐式注册
如何用配置驱动加载不同支付通道实例
不靠 init 函数或全局 map 注册，而是让 payment.NewClient() 根据 YAML/JSON 配置中的 provider: "wechat" 字段，动态返回对应实现。这样测试、灰度、多租户分渠道都容易控制。
示例配置片段：
providers:
default:
provider: wechat
app_id: wx1234567890
mch_id: 1234567890
api_v3_key: xxx
stripe:
provider: stripe
secret_key: sk_test_xxx
webhook_secret: whsec_xxx
- 配置结构体字段需包含各通道必需参数，缺失时应明确报错
"missing required field 'api_v3_key' for wechat"，而非运行时 panic - 各通道工厂函数（如
wechat.NewClientFromConfig()）只接收本通道相关字段，拒绝透传通用字段 - 避免使用
map[string]interface{}解析配置——类型不安全，IDE 无法跳转，重构易出错
NotifyVerify 方法必须隔离验签逻辑且不依赖全局状态
微信回调用证书验签，支付宝用公钥，Stripe 用签名头 + payload 拼接，三者验签流程完全不同。若共用一个 VerifySignature() 函数并塞满 if-else，后续加新通道或改老逻辑极易引入漏洞。
- 每个通道的
NotifyVerify()方法内部完成全部验签动作，包括读取 body、校验 header、解密（如有）、比对签名 - 禁止在验签前调用
r.Body.Close()或多次io.ReadAll(r.Body)，否则后续业务逻辑拿不到原始 body - 验签失败必须返回明确错误（如
payment.ErrInvalidSignature），而不是http.Error—— 上层 HTTP handler 才决定返回 400 还是 401
并发调用多个通道时如何避免 context 泄漏和超时混乱
做聚合支付或 fallback 场景（比如先调微信，超时后自动切支付宝），容易误用 context.WithTimeout 套嵌，导致子 goroutine 的 cancel 信号无法正确传递，或 timeout 被覆盖。
- 每个通道调用必须使用独立的
ctx，由上层传入统一 deadline，但不要复用同一个context.WithTimeout(parent, time.Second*15)多次 - fallback 场景推荐用
errgroup.WithContext()+eg.Go(func() error { return client.Charge(ctx, req) })，失败后主动 cancel 其他 pending 请求 - 注意微信 SDK 内部可能自带重试，若外层再套 retry 循环，可能造成重复下单；务必查清各 SDK 默认行为，必要时封装 wrapper 层禁用其重试
QueryOrderStatus() 实现和本地状态补偿逻辑兜底。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
