回调报“验签失败/签名不一致”，大概率卡在证书或参数
当面付的异步通知一到你服务器就报“验签失败/签名不一致”，通常不是支付宝“发错了”，而是你这边公钥证书没配对、回调参数被改了、或编码/解码做过头。我见过一个商户，日志里 sign 看着正常，但中间件把“+”当空格，验签直接挂。
应用公钥证书配置：最容易配错的一步
当面付走证书模式时，验签要用支付宝公钥证书里解析出来的公钥，不是你随便粘贴一段公钥字符串。
- appCertPublicKey_*.crt：应用公钥证书（用来算 app_cert_sn）
- alipayCertPublicKey_*.crt：支付宝公钥证书（用来验签）
- alipayRootCert.crt：根证书（用来算 alipay_root_cert_sn）
排查技巧：把你服务端计算出的app_cert_sn、alipay_cert_sn打到日志里，跟支付宝平台显示的是否一致；不一致就别继续看代码了，证书文件、上传位置、读取环境（容器挂载路径）优先修。
参数编码与签名串：你改动过它就会失败
常见“隐形改动”
- 用 JSON 重新序列化回调参数，导致字符顺序/转义变化
- 你做了两次 URLDecode，或框架自动解码后你又手动解码
- 把参数做了 trim，末尾空格、换行被吃掉
- charset 不是 utf-8，中文商品名一出现就不一致
验签要点：参与验签的字符串必须是原始回调参数拼接；把 sign 本身排除；按参数名排序；值不要二次加工。
回调URL与网关链路：中间层也会“动手脚”
notify_url 只要经过跳转、反代重写、WAF 清洗，就可能改参数。典型现象：同一笔订单在本地直连验签通过，上线走 CDN/网关就失败。
- 确认回调是直达你的接口，不要 302/301
- 反向代理别改 Content-Type/编码，别把“+”替换为空格
- 接口收到后原样落库/落日志一份（含全部参数）便于对比
建议你现在就做这三件事：
- 在回调入口打印：原始 query/body、charset、sign_type、app_cert_sn、alipay_cert_sn
- 用同一份回调参数在本机写个小脚本离线验签，对比线上结果，锁定是“参数变了”还是“证书不对”
- 把 notify_url 改成不经跳转的直连地址，临时绕开 CDN/WAF 验证链路问题
