hmac.Equal必须使用，因其是恒定时间比对，可防御时序攻击；而==比较字符串会因提前退出导致响应时间差异，暴露签名信息。
hmac.Equal 为什么必须用，不能直接 == 比较字符串
因为直接用 == 比较签名字符串会引入时序攻击风险：Go 的字符串比较在遇到第一个不匹配字节时就提前返回，攻击者可通过微秒级响应时间差异反推签名内容。而 hmac.Equal 是恒定时间比对，无论输入是否相等，执行路径和耗时都一致。
常见错误是先调用 hex.EncodeToString() 得到字符串，再用 == 判断——这完全破坏了安全前提。正确做法是：始终用 hex.DecodeString() 把客户端传来的 hex 签名转成 []byte，再与 mac.Sum(nil) 的原始摘要比对。
-
hmac.Equal要求两个参数都是[]byte，不能传字符串 - 如果
hex.DecodeString(signature)失败（比如长度不是 64 或含非法字符），应直接拒绝，不进入比对逻辑 - 不要对错误做差异化响应（如 “签名格式错误” vs “签名不匹配”），统一返回 401
签名消息拼接顺序必须和服务端严格一致
Python 客户端用 hmac.new(key, msg, digestmod=hashlib.sha256).hexdigest() 时，msg 是什么，Go 服务端就必须构造完全相同的字节序列。任何空格、换行、编码差异都会导致签名不匹配。
典型场景是 timestamp + token 拼接，但实际项目中更常见的是多参数组合。关键点不是“怎么拼”，而是“谁定规则、谁遵守”。服务端不能假设客户端按某种方式拼，而必须明确文档化并强制校验。
- 推荐固定字段组合：例如
timestamp+nonce+method+path+body_hash（body 做 SHA256 后取 hex） - 所有字符串值必须使用 UTF-8 编码，禁止隐式转换（如从 JSON 解析后又转 string 再拼）
- 如果用了 URL 查询参数，必须先
url.Values.Encode()，不能手拼"a="+a+"&b="+b（后者不处理特殊字符）
中间件里如何避免重复计算 HMAC
一个请求进来，可能在多个地方需要签名结果：鉴权中间件要校验、日志模块想记录、审计模块要存档。但如果每次调用都重新跑一遍 hmac.New → Write → Sum，既浪费 CPU，又可能因多次读 body 导致后续 handler 拿不到数据（HTTP body 是单次读取流）。
解决办法是把签名计算结果缓存在 context.Context 中，由中间件统一生成一次，下游按需取用。
- 在中间件开头就读一次
r.Body，用io.ReadAll转成[]byte，然后立即重置r.Body = io.NopCloser(bytes.NewReader(bodyBytes)) - 把签名结果（
[]byte）存入 context：ctx = context.WithValue(r.Context(), signatureKey, sigBytes) - 后续任何地方通过
ctx.Value(signatureKey)获取，无需再算 - 注意：body 不能太大，否则内存压力明显；超过 1MB 建议改用 streaming hash（但需自定义 Reader 包装）
时间戳校验必须在 HMAC 校验之前完成
很多人把时间戳检查放在签名验证之后，这是错的。攻击者可以构造一个过期但签名合法的请求，服务端仍会消耗资源做完整 HMAC 计算——这就是典型的 DoS 攻击面。
时间戳检查是廉价的，只需解析字符串、转 int64、比较差值。它应该作为第一道过滤器，在任何密钥操作或哈希计算前就执行。
- 建议允许最大偏移 5 分钟：
abs(now.Unix()-timestamp) > 300 - timestamp 必须是秒级 Unix 时间戳，拒绝毫秒或其他格式（避免解析歧义）
- 如果 timestamp 解析失败（如非数字、超范围），直接 400，不进后续流程
- 别忘了检查
timestamp是否为未来时间（防 NTP 漏洞或客户端时钟漂移）
