支付宝沙箱连不上或验签失败的主因是配置未对齐沙箱实时状态：公钥需上传并保存、gatewayUrl须用dev地址、appId须复制沙箱页内ID、私钥须为PKCS8格式；回调验签失败多因参数污染，应直接用getParameterMap()、确保UTF-8编码、返回纯success；异步通知需公网可达、响应200且无重定向；trade_status仅TRADE_SUCCESS和TRADE_FINISHED需处理，且须防重复通知。
支付宝沙箱环境连不上，AlipayClient 初始化就报错
多数人卡在第一步：用官方 Demo 改了参数却连不通沙箱，AlipayClient 构造时抛 AlipayApiException 或直接超时。根本原因不是代码写错，而是四个配置项没对齐沙箱后台的实时状态。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 去
https://openhome.alipay.com/platform/appDaily.htm确认「应用公钥」已上传，且「支付宝公钥」已自动生成（不是你本地生成的那对）——很多人漏点「保存」或误把应用私钥当公钥填进后台 -
gatewayUrl必须用沙箱专用地址：https://openapi.alipaydev.com/gateway.do，生产环境是openapi.alipay.com，混用必 404 -
appId要复制沙箱应用详情页里的「APPID」，不是「开发者中心」左上角那个全局 ID - 私钥必须是 PKCS8 格式（
-----BEGIN PRIVATE KEY-----开头），如果用 OpenSSL 转过，确认执行的是openssl pkcs8 -topk8 -inform PEM -in app_private_key.pem -outform PEM -nocrypt
回调验签总失败，alipayNotify.verify() 返回 false
验签失败不等于签名错，90% 是参数没过滤干净。支付宝回调会带一堆冗余参数（比如 sign_type、charset），而 SDK 的 verify() 方法只认标准业务参数，多一个、少一个、空格多一个都会导致验签失败。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 不要自己拼接
Map传给verify()；直接用request.getParameterMap()拿原始参数，SDK 内部会自动剔除非业务字段 - 确保回调接口是
POST，且 Content-Type 是application/x-www-form-urlencoded；如果用了 Spring Boot 的@RequestBody接 JSON，验签必然失败 - 检查字符集：沙箱默认用
UTF-8，但如果你的 Controller 没显式设request.setCharacterEncoding("UTF-8")，中文参数可能被转成乱码再参与验签 - 验签前先打印原始参数和
sign值，对比沙箱通知日志里的原始请求体，确认没被框架自动解码或截断
沙箱支付成功但收不到异步通知，notify_url 不生效
支付宝沙箱的异步通知机制很“脆”：它要求你的 notify_url 必须能被公网访问、响应 HTTP 200、且不能有重定向。本地开发时用 localhost 或内网 IP，沙箱服务器根本连不上。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 调试阶段必须用内网穿透工具（如
ngrok或localtunnel），把http://localhost:8080/alipay/notify映射成公网地址，填进沙箱应用的「异步通知地址」 - 回调接口必须返回纯文本
success（无空格、无换行、无 HTML 标签），返回{"code":"200"}或ok都会触发支付宝重试 - 沙箱通知有延迟（通常 1–3 分钟），别刚点完支付就刷新日志；可在沙箱后台「查看通知记录」里直接看到推送时间、状态和原始参数
- 避免在回调里做耗时操作（如查库、发邮件），支付宝超时 5 秒就会重发，容易造成重复处理
验签通过但业务逻辑出错，trade_status 判断不准
trade_status 不是只有 TRADE_SUCCESS 才算支付完成。沙箱里常见 WAIT_BUYER_PAY（用户扫码未付款）、TRADE_CLOSED（超时关闭）、TRADE_FINISHED（退款完成），但文档没说清楚哪些状态需要更新订单、哪些要忽略。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 只处理
TRADE_SUCCESS和TRADE_FINISHED；前者是首次支付成功，后者是全额退款后再次支付完成（极少见，但沙箱会模拟） -
WAIT_BUYER_PAY只说明订单创建成功，不能发货或扣库存；它可能持续几分钟，也可能直接变成TRADE_CLOSED - 务必校验
out_trade_no和trade_no是否已在数据库存在，防止同一笔通知重复消费（沙箱重试频繁，尤其网络抖动时） - 不要依赖
notify_time做时效判断，它只是支付宝发出通知的时间；以你自己收到并验签成功的时刻为准
沙箱回调验签真正难的不是算法，是参数生命周期管理——从请求进容器、到框架解析、再到 SDK 拿到原始字节流，中间任何一环被修饰或缓存，验签就失效。这点在 Tomcat 8+ 和 Spring Boot 2.3+ 里尤其隐蔽。
