直接用gin.Context.Request.URL.RawQuery会漏掉POST body，因RawQuery仅含query string而不含body，导致签名与实际请求体不一致，攻击者可篡改body绕过校验。
为什么直接用 gin.Context.Request.URL.RawQuery 会漏掉 POST body？
防篡改校验本质是签名验证，但很多人只对 URL 参数签名，忽略 POST、PUT 请求体。Gin 的 c.Request.URL.RawQuery 只含 query string，不包含 body 内容，导致签名和实际请求体不一致——攻击者可随意修改 body 而签名仍通过。
- GET 请求：签名应覆盖
RawQuery + method + path - POST/PUT 等：必须读取并参与签名的
body，且只能读一次（Request.Body是单次流） - 正确做法：在中间件中用
c.Request.Body读取原始字节，再用bytes.NewReader重置给后续 handler 使用
如何安全读取并复用 Request.Body？
Gin 默认不缓存 body，一旦 c.ShouldBindJSON() 或 c.PostForm() 调用，原始 body 就不可再读。防篡改中间件必须在绑定前完成签名计算，并把 body “还回去”。
- 调用
io.ReadAll(c.Request.Body)获取原始字节 - 立即用
c.Request.Body = io.NopCloser(bytes.NewReader(bodyBytes))恢复可读状态 - 注意：不能用
strings.NewReader，因为bytes.NewReader实现了io.ReadSeeker，部分 Gin 内部逻辑依赖 seek 能力 - 若已启用
gin.Recovery()或其他中间件提前读过 body，需确保防篡改中间件排在最前
HMAC-SHA256 签名字符串拼接顺序怎么定？
签名字符串顺序不统一，会导致客户端和服务端计算结果不一致。推荐固定格式：method|path|query|body_hash，其中 body_hash 是 body 的 sha256 哈希（避免直接拼接大 body 影响性能和长度）。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- method 全大写：如
"POST" - path 不带 query：用
c.Request.URL.Path，不是RawPath - query 用
c.Request.URL.RawQuery（保留原始编码，不 decode） - body hash 统一用
hex.EncodeToString(sha256.Sum256(bodyBytes).Sum(nil)) - 密钥必须服务端存储，禁止硬编码；建议从环境变量或 secret manager 加载
如何验证 X-Signature 头并拦截非法请求？
签名头通常叫 X-Signature 或 Authorization，需提取后与服务端计算值比对。直接用 == 比较有时间侧信道风险，应使用 subtle.ConstantTimeCompare。
立即学习“go语言免费学习笔记（深入）”；
- 从
c.GetHeader("X-Signature")取值，空或长度不符直接c.AbortWithStatus(401) - 用
base64.StdEncoding.DecodeString解码签名，失败则拒绝 - 计算服务端签名后，用
subtle.ConstantTimeCompare([]byte(expected), []byte(got)) == 1判等 - 校验失败时，不要返回具体原因（比如“签名错误” vs “过期”），统一返回 401，避免信息泄露
Request.Body 的生命周期——它不像变量，读完就没了。 
