直接比对X-Signature会失效，因签名仅防篡改不防重放；必须结合时间戳校验（如±5分钟）与nonce去重（Redis原子操作），否则攻击者可无限重放合法请求。
为什么直接比对 X-Signature 会失效
签名本身不防重放，只防篡改。如果服务端不做时间戳校验、nonce 去重或请求体一致性校验，攻击者截获一次合法请求后反复重放，X-Signature 依然能通过——因为签名是基于原始参数算出来的，重放时参数没变，签名自然不变。
HMAC-SHA256 签名生成必须包含哪些字段
签名字符串拼接顺序和内容直接影响校验成败。服务端与客户端必须严格一致，否则 hmac.Equal 必然失败。常见漏项包括：
- 所有查询参数（
c.Request.URL.Query()）和表单参数（c.PostForm）需合并排序后拼接，不能只取 query 或只取 body - 必须包含
timestamp字段，且单位统一为秒（不是毫秒），服务端应限制其有效期（如 ±5 分钟） - 必须包含
nonce字段，且需在 Redis 中做 5 分钟内去重（SET nonce "" EX 300 NX），避免一次有效签名被多次使用 -
app_key要参与签名，但不能硬编码在中间件里；应从c.GetHeader("X-App-Key")动态读取，并查库验证该 key 是否启用、是否配对正确 secret
中间件里怎么安全地读取完整请求体
GIN 默认会把 c.Request.Body 读取一次后置空，后续再调用 c.ShouldBindJSON 或手动 ioutil.ReadAll 就会得到空字节。这是签名校验最常踩的坑。
正确做法是：在中间件开头就调用 c.Request.Body = io.NopCloser(bytes.NewBuffer(bodyBytes)) 把 body 再塞回去。示例关键步骤：
bodyBytes, _ := io.ReadAll(c.Request.Body) c.Request.Body = io.NopCloser(bytes.NewBuffer(bodyBytes)) // 后续提取参数、计算签名、再绑定结构体都正常
注意：bodyBytes 必须在签名计算前读取，且不能在 c.Next() 之后才读——否则业务 handler 可能已提前消费 body。
Redis 去重和时间戳校验为什么不能分开做
单独校验 timestamp 只能防“过期重放”，单独用 nonce 只能防“同秒内重复”。两者必须原子性组合，否则存在竞态漏洞：
- 先查
timestamp合法 → 再查nonce是否存在 → 两步之间可能被并发请求插入相同 nonce - 正确方式是用 Lua 脚本一次性完成：检查时间戳有效性 +
SET ... NX EX设置 nonce，返回 1 表示通过，0 表示拒绝 - 若不用 Redis，至少要用内存 map +
sync.RWMutex做本地缓存，但要注意过期清理逻辑，否则内存泄漏
真正难的不是签名算法本身，而是如何让 timestamp、nonce、body、header 四者在校验瞬间保持逻辑闭环——任何一环脱钩，防篡改就形同虚设。
