支付回调必须验签，否则支付结果可被第三方伪造；微信用MD5验XML签名，支付宝用RSA2+SHA256验表单签名，均需按规则排序参数并忽略特定字段，且须幂等处理重试。
支付回调为什么必须验签
不验签的回调接口等于把支付结果完全交给第三方随意伪造。微信、支付宝等平台在回调请求中都会附带 sign 或 signature 字段，配合约定的密钥和参数排序规则生成，这是唯一能确认“这确实是平台发来的通知”的手段。
常见错误：直接信任 return_code=SUCCESS 和 result_code=SUCCESS 就更新订单状态——攻击者可伪造这两个字段和任意金额。
- 验签前先按平台文档要求对所有非空参数做字典序排序（注意：微信要求忽略
sign字段，支付宝要求忽略sign和sign_type） - 拼接成
key1=value1&key2=value2&key3=value3&key=YOUR_KEY格式后，用对应算法（微信是 MD5，支付宝是 RSA2 + SHA256）计算摘要 - Go 中推荐使用标准库
crypto/md5或crypto/rsa+crypto/sha256，避免第三方包引入签名逻辑黑盒
如何安全接收并解析微信支付回调
微信支付回调是 POST 请求，原始 body 是 XML 格式（不是 JSON），且要求响应必须是纯字符串 success（无空格、无换行、无 XML/JSON 包裹），否则会持续重试。
容易踩的坑：
立即学习“go语言免费学习笔记（深入）”；
- 用
r.ParseForm()或r.FormValue()读取 —— 这会失败，因为微信不发表单数据，而是 raw XML - 用
json.Unmarshal()解析 —— 类型错配，panic - 响应写了
fmt.Fprint(w, "success")但前面有日志或中间件输出了其他内容 —— 导致响应体含 HTTP header 外的杂字符，微信判定失败
正确做法：
body, _ := io.ReadAll(r.Body)
var wxNotify struct {
ReturnCode string `xml:"return_code"`
ResultCode string `xml:"result_code"`
Sign string `xml:"sign"`
OutTradeNo string `xml:"out_trade_no"`
TotalFee int `xml:"total_fee"`
// 其他字段...
}
xml.Unmarshal(body, &wxNotify)
// ✅ 验签通过后再处理业务
fmt.Fprint(w, "success") // 必须是这一行，且仅此一行
支付宝回调的异步通知与验签差异点
支付宝用的是 GET 风格的表单编码（application/x-www-form-urlencoded），但实际是 POST 请求携带该格式 body；签名字段叫 sign，算法标识是 sign_type（常见 RSA2），且公钥验签需提前加载 PEM 格式公钥。
关键区别：
- 支付宝要求对所有请求参数（除
sign和sign_type）按参数名升序拼接，值不做 URL decode —— Go 的url.Values.Encode()会自动 encode，不能直接用 - 验签必须用支付宝提供的公钥（不是你自己的私钥），且需用
crypto/x509解析 PEM 中的-----BEGIN PUBLIC KEY-----块 - 回调地址必须是外网可访问的（开发时可用 ngrok），且支付宝会主动发起多次请求，需幂等处理（例如用
out_trade_no做数据库唯一约束或 Redis setnx）
回调处理中的并发与幂等陷阱
支付平台为保证通知到达，会在失败时重试（微信最长 4 小时，支付宝最多 6 次），而你的服务可能正在扩容、重启或网络抖动，导致同一笔订单的回调被多个 goroutine 同时处理。
简单但有效的方案：
- 用数据库唯一索引：在订单表加
UNIQUE KEY(out_trade_no)，插入成功即代表首次处理，失败则跳过 - 用 Redis 做分布式锁：
SET order_123456789 "processing" EX 300 NX，设置 5 分钟过期，防止死锁 - 禁止在回调里调用外部 HTTP 接口（如发短信、推消息）—— 超时或失败会导致整个回调失败重试，应改用本地消息队列或延时任务
最常被忽略的一点：回调验签通过后，必须立即查一次商户系统内该订单当前状态。如果已是“已支付”，直接返回 success，不重复更新 —— 这比锁更轻量，也更可靠。
