Fiber处理支付回调需用ctx.Body()一次读取原始字节流，严格按平台规则验签，避免多次读取导致空签名；微信用XML+字典序拼接验签，支付宝用JSON+参数排序验签；回调必须用POST并返回纯文本"success"。
直接对接第三方支付时，Fiber 本身不提供支付逻辑，但它的中间件机制、请求解析能力和上下文控制，能让支付回调、签名验证、异步通知等关键环节更可控——前提是别把 ctx.Body() 当万能解药用。
支付回调里拿不到原始 JSON 或 XML 数据？
很多支付平台（如微信、支付宝）在回调时直接 POST 原始 application/json 或 text/xml，而 Fiber 默认只解析 application/x-www-form-urlencoded 和 multipart/form-data。一旦调用 ctx.Body() 前没手动设置，ctx.Body() 可能返回空或乱码。
- 必须在路由注册前启用
fiber.Config{DisablePreParseMultipartForm: true}，避免框架提前消费 body 流 - 对 JSON 回调：用
ctx.Body()直接读原始字节，再用json.Unmarshal解析；别用ctx.JSON()或ctx.BodyParser()，它们会触发预解析并可能失败 - 对 XML 回调（如微信）：同样用
ctx.Body()拿字节，再传给xml.Unmarshal；注意微信回调头里常带Content-Type: text/xml，Fiber 不自动识别，得自己处理
验签失败？大概率是 body 被读了两次
支付回调验签要求「原始报文」一字不差，而 Go 的 io.ReadCloser 是单次读取流。只要调用过一次 ctx.Body() 或 ctx.FormValue()，后续再读就是空的——签名自然校验不过。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 只调用一次
ctx.Body()，把结果存成[]byte变量，后续解析、验签都复用它 - 不要在中间件里偷偷读 body（比如日志中间件用了
ctx.Body()），否则下游 handler 拿到的就是空 - 微信回调需按字段字典序拼接 + 签名密钥，注意剔除
sign字段本身；支付宝则是对全部业务参数排序后拼接，再用alipay_public_key验证sign值
同步支付跳转和异步回调该用什么 HTTP 方法？
别被「回调」二字误导——微信/支付宝的服务器通知一律走 POST，且不带 CORS，也不需要你返回 JSON；而前端发起的支付请求（如调统一下单接口）通常是 POST，跳转地址则由你返回给前端，由前端 window.location.href 触发。
立即学习“go语言免费学习笔记（深入）”；
- 统一下单接口（如微信
/pay/unifiedorder）：用fiber.Post，返回map[string]interface{}给前端，其中"pay_url"或"redirect_url"字段填跳转链接 - 支付结果异步通知（如微信
/notify）：必须用fiber.Post，返回纯文本"success"（微信）或"success"（支付宝），不能加任何 HTML、JSON、换行或空格 - 千万别用
GET接收支付回调——所有主流支付平台都不支持 GET 方式推送结果
最麻烦的不是写代码，而是每个平台对「空格、换行、字段顺序、编码方式」的隐性要求不一致；微信认 UTF-8 无 BOM，支付宝要求参数值 URL decode 后再拼，而你自己写的验签函数如果漏了 trim 空格或忽略大小写，就卡在最后一步。
