验签失败主因是Gin默认不保留原始请求体，Body被读取后变空；需在中间件中用io.ReadAll提前缓存，并在任何Bind操作前完成。
为什么直接用 gin.Context.Request.Header.Get("X-Signature") 验签会失败
很多开发者一上来就从请求头取签名，再用密钥验签，结果总是 signature mismatch。根本原因不是算法写错了，而是 Gin 默认不保留原始请求体（Body）——调用 c.ShouldBindJSON() 或 c.Request.Body 读过一次后，Body 就变为空了，后续无法再次读取用于验签。
解决办法是提前把原始 Body 缓存下来：
- 在中间件里用
io.ReadAll(c.Request.Body)一次性读出全部字节 - 用
bytes.NewBuffer(bodyBytes)重新赋给c.Request.Body，供后续绑定使用 - 同时把
bodyBytes传给验签逻辑（比如拼接 timestamp + body + secret）
注意：必须在任何可能消费 Body 的操作（如 c.Bind()、c.ShouldBind()）之前执行，否则缓存的是空字节切片。
如何生成和验证基于时间戳 + 请求体的 HMAC-SHA256 签名
防篡改的核心不是加密，而是确保「谁在什么时间发了什么内容」不可伪造。推荐组合：timestamp（秒级）、nonce（随机字符串）、body（原始 JSON 字节），三者按固定顺序拼接后计算 HMAC。
立即学习“go语言免费学习笔记（深入）”；
客户端示例（伪代码）：
ts := strconv.FormatInt(time.Now().Unix(), 10)
nonce := "a1b2c3"
body := []byte(`{"user_id":123,"amount":100}`)
sig := hmacSha256([]byte(ts + nonce + string(body)), []byte("your-secret-key"))
// 发送 Header: X-Timestamp: ts, X-Nonce: nonce, X-Signature: hex.EncodeToString(sig)
服务端验签要点：
- 先校验
X-Timestamp是否在允许窗口内（如 ±300 秒），防止重放 - 检查
X-Nonce是否已用过（需配合 Redis 做短时去重） - 用完全相同的拼接规则（顺序、无空格、无换行）复现原始输入，再算一次 HMAC 对比
- 务必用
hmac.Equal()而非==比较签名，避免时序攻击
Gin 中实现签名中间件要注意哪些兼容性细节
不是所有接口都需要验签，也不是所有请求体都是 JSON。中间件得灵活适配：
- 跳过 OPTIONS 预检请求：
if c.Request.Method == "OPTIONS" { c.Next(); return } - 区分 Content-Type：
application/json才读 Body；application/x-www-form-urlencoded应用c.Request.PostFormValue()拼原文；纯查询参数接口可只验 query + timestamp - 路径白名单控制：
if strings.HasPrefix(c.Request.URL.Path, "/public/") { c.Next(); return } - 错误响应统一用
c.AbortWithStatusJSON(401, gin.H{"error": "invalid signature"})，别 panic 或 log.Fatal
另外，Gin 的 c.Request.RemoteAddr 可能是反向代理 IP，真客户端 IP 得从 X-Forwarded-For 解析（但该头可伪造，仅作参考，不可用于安全决策）。
为什么用 time.Now().Unix() 而不用 time.Now().UnixMilli()
毫秒级时间戳看似更精确，但实际增加了客户端和服务端时钟漂移导致验签失败的概率。网络传输延迟、客户端系统时间不准、服务端 NTP 同步误差……几毫秒偏差就足以让 abs(serverTs - clientTs) > 300000。
用秒级时间戳 + 5 分钟容忍窗口，既满足防重放需求，又大幅降低误拒率。真正需要更高精度的场景（比如金融级幂等），应该用服务端下发 nonce + Redis Lua 原子校验，而不是靠时间戳精度硬扛。
另外，time.Now().Unix() 返回 int64，直接转字符串无格式问题；而 milli 版本在某些旧 Go 版本或跨平台编译时可能有符号扩展隐患，不值得为这点“精度”添麻烦。
