仅校验timestamp无法防御重放攻击，因攻击者可在5分钟窗口内重发完整请求；必须结合Redis原子写入nonce（SET key EX 300 NX）、严格统一签名原文拼接规则、标准化body、常量时间验签及限制timestamp不超当前时间。
为什么只校验 timestamp 会放行重放请求
服务端用 abs(time.Now().UnixMilli() - req.Timestamp) > 300000 判断是否超时，看似能拦住老请求，但攻击者只要在 5 分钟窗口内把抓到的完整请求（含 timestamp、nonce、X-Signature）原样重发，校验就全过。签名不变、时间仍在窗口内、nonce 若没做原子去重，也查不到——结果就是同一笔登录或支付被反复执行。
nonce 必须用 Redis 的 SET key value EX 300 NX 原子写入
不能先 GET 再 SET，也不能只存内存或用 sync.Map。多实例部署下，本地缓存完全失效；高并发时 GET+SET 中间存在竞态窗口，两个请求同时判定“未存在”，都会写入成功。
- key 建议格式：
auth:nonce:{md5(nonce)}或auth:nonce:{userID}:{nonce}，避免长字符串作 key 影响性能，也防不同用户撞 nonce - 必须用
NX（仅当 key 不存在时设置），配合EX 300（5 分钟过期），一条命令完成“首次写入 + 自动清理” - 若 Redis 返回
redis.Nil，说明已存在 → 直接返回403 Forbidden，不进后续逻辑
签名原文拼接顺序和 body 处理是验签失败主因
客户端和服务端拼接签名原文的顺序、字段、编码必须严格一致，差一个空格或 key 排序不同，HMAC-SHA256 结果就完全不同。常见坑点：
Echo框架 5.1.0
下载
Echo框架 5.1.0 版本源码包下载，适合关注 RealIP 行为变化、StartConfig.Listener、NewDefaultFS 和观测性中间件入口的开发团队。
- body 必须读取一次后重置：
c.Request().Body是单次流，中间件里读完要调用c.Request().Body = io.NopCloser(bytes.NewBuffer(bodyBytes))，否则后续 handler 拿不到数据 - JSON body 要先
json.Unmarshal再按字典序sort.Stringskey，再json.Marshal标准化，不能直接用原始 bytes 拼接 - 签名原文必须包含：
method（大写） +path（不含 query string） +timestamp（毫秒整数字符串） +nonce（原始字符串） +body（标准化后 bytes） - 密钥绝不能硬编码，建议从环境变量或 Vault 加载，且用
hmac.Equal或hmac.compare_digest（Go 中需自己实现常量时间比较）防侧信道攻击
时间戳校验要拒绝未来时间，不止容忍偏差
只做 abs(now - timestamp) 不够。攻击者可把手机时间调快几小时，构造一个远大于当前时间的 <code>timestamp，只要不超窗口，签名依然有效。正确做法是双限：
- 下限：
timestamp >= now - 300000（5 分钟前） - 上限：
timestamp （只允许未来 10 秒，防客户端时钟严重超前） - 务必用
time.Now().UnixMilli()，不是Unix()，毫秒级更抗网络抖动和时钟漂移
这个 10 秒上限容易被忽略，但它堵死了“调快本地时间 + 长期重放”的路子。真正上线时，这个边界比“±5 分钟”更关键。
