ThinkPHP处理支付回调必须直取原始输入流、手动验签、严格返回标准XML响应，并用trade_no唯一索引实现幂等，否则将导致验签失败、重复发货或平台持续重发。
ThinkPHP 处理支付回调不能依赖框架默认的请求解析逻辑，必须直取原始输入流、手动验签、严格响应格式，并用数据库唯一索引兜底幂等性——否则 90% 的「验签失败」「重复发货」「微信/支付宝一直重发」都源于这三步做错。
为什么 $this->request->post() 和 input('xxx') 拿不到微信/支付宝回调数据
微信发的是 raw XML，支付宝发的是 raw query string，Content-Type 多为 text/xml 或 application/x-www-form-urlencoded 但无标准表单边界；支付宝 v3、微信 v3 甚至发 AES 加密 JSON。ThinkPHP 默认只解析 application/x-www-form-urlencoded 和 multipart/form-data，其他类型一律跳过，$_POST 为空是正常现象。
常见错误包括：
- 在控制器里直接写
input('out_trade_no')，返回空，然后误判“不是有效回调” - 用
$this->request->param()却没调bind('json', true)，对 JSON 回调解析失败 - 混用
$_POST和file_get_contents('php://input')，后者第二次读返回空字符串
正确做法：入口第一行就定死数据源——微信 XML 用 file_get_contents('php://input')；支付宝原始字符串也用它；v3 加密 JSON 必须先解密再 json_decode()，不能跳过解密直接 decode。
立即学习“PHP免费学习笔记（深入）”；
验签失败的三个硬性检查点
验签不是比对一个 hash，而是还原签名原文的过程。任何环节编码/顺序/字段遗漏都会导致失败。
- 微信 v2：剔除
sign字段后，所有剩余字段（含sign_type）按字典升序拼成k1=v1&k2=v2，末尾加&key=YOUR_KEY，全部 UTF-8 编码后再 MD5；cash_fee等数字字段值不能转成 int，必须保持字符串原样参与拼接 - 支付宝：原始字符串（非数组）先
urldecode()，再用parse_str()转数组，剔除sign和sign_type，键名升序排列后用&拼接，不加 key，最后用 RSA 公钥验签；alipay_config['rsa_public_key']必须是 PEM 格式且开头为-----BEGIN PUBLIC KEY----- - 微信 v3：不能手写验签，必须用官方
wechatpay-phpSDK，构造WechatPayMiddleware，传入平台证书私钥和序列号；回调体是 AES-GCM 加密 JSON，直接json_decode()必然为空或乱码
回调成功后更新订单为什么还要防重放
支付平台会因网络超时、你返回非 200、响应含 BOM/空格/额外输出等原因持续重推同一笔通知，最长可达 24 小时。仅靠查 out_trade_no 是否存在无法解决并发冲突。
- 两个请求同时查到“订单未支付”，都会执行更新 → 状态被覆盖两次，但发货逻辑可能跑两遍
- 用
SELECT ... FOR UPDATE加行锁可行，但锁粒度大、易阻塞，且 Redis 分布式锁在回调场景下不可靠（锁失效窗口 + 网络分区） - 最稳方案：在订单表加
trade_no字段（微信的transaction_id或支付宝的trade_no），建唯一索引，业务层用INSERT IGNORE INTO pay_log (...) VALUES (...)或ON DUPLICATE KEY UPDATE写日志表；成功插入即首次处理，失败说明已存在，直接跳过后续操作
为什么 return 'SUCCESS' 还是被微信一直重发
微信只认严格符合规范的 XML 响应体，任何偏差都会判定为失败并重试。
- 响应 Content-Type 必须是
text/xml，不能是application/xml或缺失 - 响应体只能是纯 XML：
<xml><return_code>SUCCESS</return_code><return_msg>OK</return_msg></xml>，前后不能有空格、换行、BOM、echo、var_dump、日志输出 - ThinkPHP 开启
app_debug = true时，会自动在响应前注入调试 HTML，必须关掉；上线环境务必确认app_debug = false - 不要用
echo 'SUCCESS'或return $pay->success()后再执行其他逻辑——success() 方法内部已输出，后续代码若触发输出就会污染响应体
最易忽略的是响应头和输出缓冲：TP6 默认启用 output buffer，需在回调入口加 ob_end_clean(); 并显式设置 header，否则 nginx 可能缓存或截断响应。
