buffalo框架不内置支付逻辑，需手动实现支付宝回调验签、幂等控制与订单更新；必须用io.readall读原始body并重建，按字典序拼接原始字符串验签，数据库用select for update+严格状态条件防重入，沙箱需公网https回调地址。
Buffalo 框架本身不内置支付适配逻辑，处理支付宝回调必须手动实现验签、解析、幂等控制和业务更新——它和 Gin/Echo 一样，只提供 HTTP 路由与请求解析能力，所有支付安全细节得自己补全。
为什么不能直接用 buffalo.Context#Request().Body 读取支付宝回调
支付宝回调是 application/x-www-form-urlencoded 编码的 POST 请求，但 Body 可能被中间件（如 pop 或日志中间件）提前读取并关闭，导致后续 ctx.Request().ParseForm() 失败或 io.EOF。常见错误现象：http: invalid Read on closed Body。
- 始终在路由 handler 开头调用
ctx.Request().ParseForm()，不要依赖ctx.Request().Body手动读取 - 若需原始数据做验签（支付宝要求对原始字符串验签），必须用
io.ReadAll(ctx.Request().Body)一次读完，并用bytes.NewBuffer重建Body供后续解析（注意：这会绕过中间件缓存，需自行协调） - Buffalo 默认不自动解析 form，不调用
ParseForm就直接访问ctx.Param或ctx.Request().PostForm会返回空值
验签前必须正确还原支付宝原始通知字符串
支付宝文档明确要求：验签必须使用「未解析、未解码、原始字节流」拼接出的字符串（按 key 字典序排序，key=value 连接，不带 & 结尾）。Buffalo 的 ctx.Request().Form 已解码且丢失原始顺序，不可用于验签。
Buffalo框架 1.0.1
下载
Buffalo框架 1.0.1 版本源码包下载，适合需要错误处理改进、依赖更新、render.Download 注释和 request logger 调整的 v1 项目。
- 在 handler 开头立即执行：
raw, _ := io.ReadAll(ctx.Request().Body) - 用
url.ParseQuery(string(raw))解析出 map，再手动按 key 排序拼接（别用ctx.Request().PostForm） - 确保使用支付宝公钥（不是应用公钥！）和
RSA2算法验证；公钥格式必须是-----BEGIN PUBLIC KEY-----...，开头结尾换行符不能丢 - 验签失败一律返回
"failure"（纯文本，无 HTML/JSON），且 HTTP 状态码必须是200，否则支付宝会持续重发
如何安全地更新订单状态并避免重复处理
支付宝回调无序、可重发，且不保证 exactly-once。Buffalo 项目里没内置分布式锁或消息队列时，仅靠数据库唯一约束 + SELECT FOR UPDATE 容易在高并发下漏锁。
- 在事务内先
SELECT ... FOR UPDATE WHERE out_trade_no = ? AND status = 'pending'，查不到就直接返回 success（说明已处理） - 更新时用
UPDATE orders SET status = 'paid', paid_at = NOW() WHERE out_trade_no = ? AND status = 'pending'，检查RowsAffected == 1确认真更新了 - 不要用
status IN ('pending', 'processing')这类宽松条件——重试时可能把“处理中”误标为“已支付” - 记录完整回调原始内容到日志表（含 timestamp、sign、out_trade_no），排查时比内存日志可靠得多
最常被忽略的是：支付宝沙箱环境回调地址必须是公网可访问的（哪怕用 ngrok），且生产环境必须用 HTTPS；本地 localhost 直接收不到任何通知——这不是 Buffalo 的问题，但新手总卡在这一步。
