签名验证中间件必须注册在gin.Recovery()之后、业务处理之前，且须在gin.Logger()之前，以避免Body被提前读取；应统一用c.GetRawData()读取并缓存请求体，按约定要素（method、path、query、body、timestamp等）标准化后生成HMAC-SHA256签名比对。
签名验证该放在Gin的哪个中间件位置
必须放在路由匹配之后、业务处理之前，否则无法拿到完整请求参数；也不能放在 gin.Logger() 之后再做验签，因为某些日志中间件会提前读取 c.Request.Body，导致后续 c.ShouldBindJSON() 或 c.PostForm() 拿不到原始数据。
推荐注册顺序：gin.Recovery() → yourSignVerifyMiddleware() → 其他业务中间件（如JWT校验）→ 路由处理函数
- 用
c.Request.URL.RawQuery拼接查询参数，注意保持参数键值顺序一致（建议按字典序排序） - POST/PUT 的 body 必须只读一次：用
c.Request.Body前先调用c.Request.Body = io.NopCloser(bytes.NewBuffer(bodyBytes))回填，否则后续绑定失败 - 避免在中间件里直接调用
c.ShouldBindJSON()，它会消费 body；应统一用c.GetRawData()提前读取并缓存
如何安全生成和比对签名字符串
签名本质是服务端用约定密钥 + 请求要素（method、path、query、body、timestamp）生成摘要，与客户端传来的 sign 字段比对。关键不是“怎么算”，而是“哪些字段必须参与、顺序是否固定、编码是否一致”。
常见漏点：timestamp 参数未校验时效性（建议允许 5 分钟偏差），nonce 未做防重放（需 Redis 记录已用 nonce + TTL），URL path 未去除末尾斜杠或多余空格。
立即学习“go语言免费学习笔记（深入）”；
- 拼接字符串时，所有参数值必须做
url.QueryEscape()，包括 query 和 form data 中的 value - body 参与签名前，要标准化 JSON：去掉空格、key 按字母序排列（用
jsoniter.ConfigCompatibleWithStandardLibrary配合Marshal再解析重排） - 签名算法优先选
hmac.Newsha256，密钥不要硬编码，从环境变量或配置中心加载
如何处理不同 Content-Type 的请求体
不是所有请求都走 JSON；application/x-www-form-urlencoded、multipart/form-data、纯文本甚至空 body 都得兼容，否则验签中间件一遇到非 JSON 就 panic 或跳过校验。
判断依据不能只看 header，还要 fallback 到实际内容：比如 header 是 application/json 但 body 是空或乱码，应返回 400 而非继续验签。
-
Content-Type: application/json→ 用c.GetRawData()读 body，尝试 json.Unmarshal 验证结构，失败则拒收 -
Content-Type: application/x-www-form-urlencoded→ 用c.Request.PostForm获取 map，再按 key 排序拼接 -
Content-Type: multipart/form-data→ 不建议 body 参与签名（文件上传不可控），仅校验 text 字段 + query + timestamp - 无 body 请求（GET/DELETE）→ 签名只基于 method + path + query
调试阶段怎么快速定位验签失败原因
生产环境不能打明文密钥和完整签名串，但开发时可在中间件里加条件日志：当 GIN_MODE=debug 且请求带 X-Debug-Sign: true 时，返回 200 并附带服务端计算出的待签名原文和 hex 版 hmac 值，方便和客户端对齐。
- 客户端传的
sign是 base64 还是 hex？服务端解码方式必须严格对应 - 注意大小写：HTTP header 中的
X-Sign在 Go 里是c.GetHeader("X-Sign")，不是"x-sign" - 时间戳用的是秒还是毫秒？服务端解析时用
time.Unix(timestamp, 0)还是time.Unix(0, timestamp*int64(time.Millisecond))
最常被忽略的是 query 参数的编码差异——客户端用 encodeURIComponent，Go 用 url.QueryEscape，两者对中文、空格、斜杠的处理一致，但对 +（空格）和 %20 的互转容易出错。真出问题时，先打印两边拼出来的原始字符串再比对。
