只校验时间戳无效，必须结合nonce与Redis原子校验：key为"user:nonce"，用SET NX EX确保唯一性与自动过期，timestamp和nonce须明文传输且签名原文中严格一致。
只校验时间戳是无效的防重放——攻击者在窗口期内重发一次合法请求就成功了。真正要拦住的是“同一个签名+参数组合只能被接受一次”，必须引入服务端可验证、不可复用的状态，比如 nonce 或滑动窗口。
为什么不能只靠 time.Now().Sub(req.Timestamp) 校验
重放攻击不是“接口被调用多次”，而是“合法签名的旧请求被截获后再次提交”。如果只检查 timestamp 是否在 ±180 秒内，攻击者只要在该窗口内把抓到的完整请求（含签名、timestamp、nonce）原样重发，服务端仍会认为它合法。
- 签名本身没变，密钥没泄露，HMAC 验证必然通过
-
timestamp仍在有效区间，时间校验也通过 - 但这个请求本应只处理一次——缺少“已消费”状态标记
必须用 Redis 做原子性 nonce 校验（生产首选）
本地内存方案在多实例或高并发下极易失效，Redis 的 SET key value EX 300 NX 是目前最可靠、最轻量的落地方式。关键不是“存”，而是“存的同时确保它没被用过，且自动过期”。
-
key必须带用户/设备维度，例如fmt.Sprintf("nonce:%s:%s", userID, req.Nonce)，避免不同用户撞nonce - 务必用
NX（仅当 key 不存在时设置），禁止先GET再SET——中间有竞态窗口 -
EX 300表示 5 分钟过期，应 ≥ 网络最大延迟 + 服务处理耗时，但不宜超过业务允许的最大时钟偏差（如客户端与服务器时间差） - 若返回
redis.ErrNil，说明 key 已存在 → 重放已发生，直接拒绝
客户端签名原文里必须明传 timestamp 和 nonce
这两项不能只塞进签名原文里不暴露，必须作为独立 HTTP 参数（如 query 或 header）明文传输，否则服务端无法提取并校验。
-
timestamp推荐用time.Now().UnixMilli()（毫秒级），比秒级更抗时钟漂移 -
nonce必须每次请求都重新生成，用crypto/rand.Read()生成 16 字节随机数，再转hex.EncodeToString或base64.StdEncoding.EncodeToString - 常见错误：把
nonce写死在客户端、或只用时间戳不用nonce、或签名原文拼接顺序不一致导致服务端验签失败
没有 Redis 时的降级方案：本地滑动窗口 + 定时清理
仅适用于单机部署、QPS 较低、且能接受极小概率漏判的内部工具类 API。核心是维护一个带时间戳的 map[string]time.Time，并用 sync.RWMutex 保护读写。
- 不能用
sync.Map——它不支持按值删除，无法实现“过期自动清理” - 需起一个 goroutine 定期（如每 30 秒）遍历 map，删掉
time.Since(t) > window的条目 - 每次
Check(nonce)前先读，命中则判断是否超时；未命中或超时则写入新记录 - 注意：该方案在进程重启后状态丢失，且多实例下完全失效
真正难的不是写几行 SET NX EX，而是把 userID、nonce、timestamp、签名原文拼接规则、过期窗口、时钟偏差容忍度这几件事在客户端和服务端严格对齐——漏掉任意一环，防重放就形同虚设。
