只校验timestamp会放行重放攻击，因它仅验证请求是否“不过期”，无法识别“同一合法请求是否已被处理过”；必须结合带用户维度的nonce与redis原子操作（set key ex nx）确保签名+参数组合仅一次有效。

为什么只校验 timestamp 会放行重放请求

攻击者截获一次合法请求（含正确签名、timestamp、nonce），只要在服务端设定的时间窗口内原样重发，HMAC 验证通过、time.Now().Unix() - req.Timestamp 也落在允许范围内，整个请求就被照单执行——这正是重放攻击成功的关键路径。

时间戳只解决“太旧的请求不处理”，不解决“同一合法请求是否已被处理过”。防重放的本质是拒绝“签名+参数+时间+随机数”这一整套组合的第二次出现。

• 仅用 timestamp 校验，等于给攻击者开了一个固定时长的重放窗口
• nonce 若未绑定用户维度（如拼接 userID），不同用户可能生成相同值，导致误拒或漏判
• 若 nonce 存储不用原子操作（比如先 GET 再 SET），高并发下两个请求可能同时读到“不存在”，然后都写入，彻底失效

用 Redis 的 SET key value EX ttl NX 做原子校验

这是生产环境最轻量且可靠的落地方式。它在一个命令里完成“判断是否存在 + 不存在才设置 + 设置即带过期”，没有竞态窗口。

关键点不是“存 nonce”，而是“存的同时确保它没被用过，且自动过期”：

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

• key 必须带用户粒度，例如 fmt.Sprintf("nonce:%s:%s", userID, req.Nonce)，避免全局冲突
• EX 值应 ≥ 客户端最大网络延迟 + 服务端处理耗时，但不宜超过业务允许的最大时钟偏差（比如客户端和服务端时间差 ≤ 2 分钟，则设 EX 240 比 EX 300 更稳妥）
• 返回 redis.ErrNil 表示 key 已存在 → 重放已发生，直接拒绝；其他错误需按实际处理（如连接失败应记录并允许降级）
• userID 必须来自可信上下文（如 JWT 解析后的 sub 字段），不能从请求参数中直接取，否则可被伪造

客户端必须明文传 X-Timestamp 和 X-Nonce

这两项不能只塞进签名原文里不暴露，否则服务端无法提取并参与验签和去重校验。

• timestamp 推荐用 time.Now().UnixMilli()（毫秒级整数），比 Unix() 更抗时钟漂移；服务端解析时也必须用毫秒，避免单位错位
• nonce 必须每次请求都重新生成，用 crypto/rand.Read() 生成 16 字节随机数，再转 hex.EncodeToString() 或 base64.StdEncoding.EncodeToString()
• 常见错误：把 nonce 写死、或只传 timestamp 不传 nonce、或签名原文拼接顺序与服务端不一致（比如客户端拼 method+path+body+timestamp+nonce，服务端却按 method+path+timestamp+nonce+body）

没有 Redis 时的本地滑动窗口降级方案

仅适用于单机部署、QPS 较低、且能接受极小概率漏判的内部工具类 API。

• 用 sync.RWMutex 保护一个 map[string]time.Time，key 是 userID:nonce 或 sha256.Sum256(body)[:8]（省去传参）
• 不能用 sync.Map —— 它不支持按值删除，无法实现“过期自动清理”
• 需起一个 goroutine 定期（如每 30 秒）遍历 map，删掉 time.Since(t) > window 的条目
• 多实例部署下该方案完全失效，因为状态不共享；一旦上生产，必须切回 Redis 或数据库方案

真正难的不是写对那一行 conn.Do("SET", ...)，而是保证客户端和服务端对 timestamp 单位、nonce 生成方式、签名原文拼接顺序、userID 来源这四点完全一致——任何一处脱节，验签或去重就会静默失败。

golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！