单纯校验X-Signature头部无法防篡改，必须绑定timestamp（毫秒级，≤5分钟偏差）、nonce（X-Nonce头取，32字符）、原始body、method与path，按固定顺序拼接签名原文，并在Redis原子校验nonce，失败时降级仅校验timestamp。
单纯校验 X-Signature 头部是否匹配，不结合 timestamp、nonce 和请求体一致性校验，防不住篡改——攻击者可截获一次合法请求，改掉参数再重发，只要签名还对就得放行。
验签必须包含 timestamp + nonce + body 的完整绑定
签名原文不是“随便拼几个字段”，而是固定顺序的确定性字符串。漏掉任意一环，验签就形同虚设：
-
timestamp必须是毫秒级整数，服务端用time.Now().UnixMilli()计算差值，容忍窗口建议 ≤ 300000ms（5 分钟），且要校验是否为未来时间（允许最多 10 秒漂移） -
nonce必须从X-Nonceheader 取，长度建议 32 字符（如 UUID v4 hex），不能走 query 或 body，避免被 CDN 缓存或日志误记 -
body必须在中间件里提前读取一次并重置：bodyBytes, _ := io.ReadAll(c.Request.Body)→c.Request.Body = io.NopCloser(bytes.NewReader(bodyBytes))，否则后续c.ShouldBindJSON()会失败 - 签名原文拼接顺序必须严格一致：例如
method + "\n" + path + "\n" + timestamp + "\n" + nonce + "\n" + string(bodyBytes)，前后端字段排序、空格、换行符都要统一
Gin 中间件里怎么安全读 body 并验签
常见错误是直接 json.NewDecoder(c.Request.Body).Decode() 或调用 c.ShouldBindJSON() 后才去算签名——此时 Request.Body 已 EOF，签名原文里的 body 就是空的，必然校验失败。
- 验签中间件必须放在所有解析 body 的操作之前，且
c.Next()要写在校验通过之后 - 读取
body前先检查c.Request.ContentLength，超限直接c.AbortWithStatus(413)，避免 OOM - 签名计算用
hmac.Equal()比较，不用==，防止时序攻击 - 密钥不硬编码，从
viper.GetString("auth.secret_key")或 Vault 动态加载；不同 client 应分配不同accessKey/secretKey对
Redis 校验 nonce 是否已用过，失败时怎么降级
Redis 不可用时，不能直接跳过 nonce 校验——那等于开放重放通道。必须有明确的降级策略：
- 用
redis.SetNX(ctx, "nonce:"+nonce, "1", 300*time.Second)，返回false表示已存在，立即c.AbortWithStatus(401) - 若 Redis 连接失败（
ctx.DeadlineExceeded或redis.Nil以外的 error），降级为仅校验timestamp有效性，并记录告警日志：log.Warn("redis unavailable, skipping nonce check") - 绝对不要 fallback 到本地 map +
sync.RWMutex——多实例部署下完全无效，且易引发内存泄漏 - GET 请求默认跳过整个验签链，但若业务上 GET 也带敏感参数（如删除标记），需显式启用，不能依赖 method 自动过滤
真正难的不是写对 hmac 计算，而是让 timestamp、nonce、body、path、method 这五个要素在前后端始终以完全相同的字节序列参与签名——任何一处空格、大小写、排序差异，都会导致验签失败。调试时建议在开发环境把签名原文和计算出的 X-Signature 都打到日志里，逐字比对。
