对账逻辑应采用策略模式而非if-else堆砌，按支付平台拆分为verifynotify、fetchorderdetail、reconcile三个接口，由reconciliationcontext注入http客户端、日志和配置实现解耦，并在上下文中兜底处理重复通知、两级校验、查单失败等边界情况。
对账逻辑不能靠 if-else 堆出来，否则每加一个支付平台就要改一次主流程，线上出问题时根本不敢动。
为什么直接在订单回调里写对账逻辑会崩
微信支付回调验签用 openssl_verify + sha256WithRSAEncryption，支付宝用 openssl_verify + SHA256withRSA（注意大小写和空格），银联又用 md5 + 本地密钥拼接。硬编码进一个方法里，光签名验证就三套逻辑混着走；更别说异步通知字段名不统一（out_trade_no vs orderNo vs tn）、金额单位不一致（分 vs 元）、状态码含义不同（success 在微信是支付成功，在银联可能是交易受理成功但未扣款）。
- 每次新增渠道都要改
handleNotify()，违反开闭原则 - 测试必须覆盖所有组合：微信回调+重复通知、支付宝回调+验签失败、银联回调+金额为0
- 对账结果入库前缺少统一字段映射，导致后续查账要写 N 个
WHERE条件
用策略模式拆解对账行为的三个关键接口
不是所有“对账”都一样：微信要查 transaction_id 并比对 total_fee 和 cash_fee，支付宝要调 alipay.trade.query 接口再核对 pay_amount 和 receipt_amount，银联要走 queryTransDetail 并校验 origQryId。所以策略接口得暴露三件事：
-
verifyNotify(array $data): bool—— 验证原始通知是否可信（签名、时间戳、来源 IP 白名单） -
fetchOrderDetail(string $tradeNo): array—— 主动查单，返回标准化字段：['amount' => 1000, 'status' => 'success', 'paid_at' => '2026-04-20 15:00:00'] -
reconcile(array $notifyData, array $detail): bool—— 对比通知与查单结果，返回是否一致
注意：不要让策略类直接操作数据库或发 HTTP 请求，这些应由上下文或独立服务提供，策略只负责判断逻辑。
上下文类必须隔离支付平台敏感操作
ReconciliationContext 不该持有 curl_init() 或 PDO 实例，而应通过构造函数注入依赖：
- 传入统一的 HTTP 客户端（如
GuzzleHttp\Client），由它处理超时、重试、证书路径 - 传入日志实例（如
Psr\Log\LoggerInterface），记录每笔对账的输入/输出，方便审计 - 传入配置数组，例如
['wechat' => ['cert_path' => '/path/to/apiclient_cert.pem']]，避免策略类自己读配置文件
这样，当某天微信升级了证书格式，你只需要改配置和初始化逻辑，所有策略类照常运行。
容易被忽略的边界情况
真实对账不是“通知来了→查单→比对→完事”。以下五点漏掉任一，都会导致资金差错：
- 微信回调可能带
result_code=SUCCESS但return_code=FAIL，必须两级校验 - 支付宝
trade_status是TRADE_SUCCESS，但实际到账可能延迟，对账时得看pay_amount是否等于订单金额 - 银联通知里的
respCode是00仅表示受理成功，要查单确认settleDate是否已落账 - 重复通知必须幂等处理：同一
out_trade_no+ 相同sign的请求，第二次进来直接返回 success，不重跑对账 - 查单失败不能静默跳过——要记录
failed_to_fetch_detail状态，并触发告警，人工介入
这些不是策略能自动解决的，得在上下文里用 try/catch + 状态标记兜底，否则策略再干净，线上照样丢钱。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
