最稳妥的选择是使用官方 SDK，但需确保 PHP 版本、扩展及配置合规：微信必须用 wechatpay-php（v3），支付宝需区分 alipay-sdk-php（PHP≥7.2）与 alipay-easysdk（PHP≥7.4），验签须用原始请求体、严格校验时间戳与参数顺序，回调处理应解耦事务与幂等控制。
直接用官方 SDK 是最稳妥的选择，但前提是它真能跑通——很多项目卡在第一步就因为 PHP 版本、扩展缺失或 composer 加载失败。
微信 v3 接口必须用 wechatpay-php，别碰非官方包
GitHub 上搜 wechatpay 会出来一堆同名库，其中只有 wechatpay-php（由微信官方维护）支持 v3 API 的完整签名验签逻辑。其他包要么只封装了 v2 XML，要么验签时漏校验 WECHATPAY-TIMESTAMP 和 WECHATPAY-NONCE，导致回调总失败。
- PHP ≥ 7.2，且必须启用
openssl、curl、json扩展 - 初始化时传入的私钥必须是 PEM 格式，且不能带密码；证书路径要写绝对路径，相对路径在 CLI 或队列中容易失效
- 验签函数
verifySignature()必须传入原始请求体（$request->getRawBody()），不是$_POST或$request->post()解析后的数组 - 时间戳校验默认容忍 5 分钟偏差，线上服务器时间不准会导致批量验签失败，建议加
ntpdate定时同步
支付宝新旧 SDK 切换：别混用 alipay-sdk-php 和 alipay-easysdk
alipay-sdk-php（老版）和 alipay-easysdk（新版）不兼容。前者依赖 AopClient 和手动拼参，后者用 AlipayClient + 对象化请求，且强制要求 PHP ≥ 7.4。
- 老项目还在用 PHP 7.2/7.3？只能用
alipay-sdk-php，别强行升级 SDK -
AlipayAopClient::rsaCheckV1()验签前必须过滤空值、sign字段本身，且参数要按字典序排序后拼接 —— 少一步都会返回 false - 异步通知里
$_POST是空的？检查是否开了always_populate_raw_post_data（PHP 5.6+ 已废弃），改用file_get_contents('php://input') - 新版
alipay-easysdk的AlipayClient::execute()默认走网关重试，超时设置需显式传connect_timeout和read_timeout
ThinkPHP/Laravel 中支付逻辑必须拆出 Controller
把 WxPayService::createOrder()、验签、订单更新全塞进一个 PayController@notify 方法里，等于把事务控制、幂等校验、日志追踪全锁死在 HTTP 生命周期内。
立即学习“PHP免费学习笔记（深入）”；
- TP6 建议在中间件里做验签，用
$request->getRawBody()拿原始数据，避免框架自动解析破坏 XML/JSON 结构 - Laravel 应该用
HandleWxPayNotifyJob处理回调，job 内用 DB transaction 包裹状态更新，并设uniqueId防重复消费 - 验签通过后，不要立刻查库更新；先查订单当前状态，仅当为
pending时才执行后续动作，否则直接返回success - 所有敏感参数（如密钥、证书路径）必须从环境变量读取，绝不能硬编码在 config 数组里
手写 cURL 调 v3 或支付宝 API 时最容易漏的三件事
不用 SDK 并不意味着更自由，反而更容易在签名、编码、响应处理上翻车。
- 微信 v3 签名字符串必须是「HTTP 方法 + \n + 请求路径 + \n + 时间戳 + \n + 随机串 + \n + 请求体 SHA256」五段拼接，缺一不可；很多人漏了换行符或误用 base64 编码请求体
- 支付宝
biz_content是 JSON 字符串，但整个请求参数要 urlencoded 后再签名，顺序错或编码不一致就会验签失败 - 收到回调后，必须原样返回
success（纯文本，无 HTML、无空格、无 BOM），否则微信/支付宝会持续重推，可能造成订单状态被多次更新
真正难的从来不是调通第一次支付，而是让回调在高并发、网络抖动、服务器重启后依然稳定可靠——验签逻辑是否独立、状态更新是否包裹在事务里、重复通知是否被拦截，这些细节比选哪个 SDK 更决定成败。
