nonce必须含纳秒级时间戳与不可预测随机源（如uuid），服务端需同时校验时效性（≤5分钟）和缓存去重（redis setnx），header传输更安全，签名须包含nonce，校验链路需原子化与时钟同步。
Nonce 必须带时间戳和唯一标识，不能只靠 rand.Intn
单纯用 rand.Intn(1000000) 生成的数字既不唯一也不可验证，攻击者截获一次请求就能重放无数次。真正可用的 Nonce 必须满足：服务端能校验它是否“新鲜”、是否“未使用过”、且客户端无法预测。推荐组合方式是：base64.StdEncoding.EncodeToString([]byte(fmt.Sprintf("%d-%s", time.Now().UnixNano(), uuid.NewString())))。注意两点：一是时间精度必须到纳秒（UnixNano()），避免高并发下重复；二是必须拼接不可预测的随机源（如 uuid.NewString()），不能只靠时间——否则时间可控时，Nonce 就可被穷举。
服务端必须做两层校验：时效性 + 去重缓存
收到请求后，服务端要立刻解析 Nonce 中的时间戳，拒绝超过 5 分钟（或业务允许的最大偏移）的请求；同时查缓存（如 Redis）确认该 Nonce 是否已存在。这两步缺一不可：
- 只校验时间不查缓存 → 攻击者可在有效期内无限重放同一 Nonce
- 只查缓存不校验时间 → 缓存击穿或误删后，旧 Nonce 可能被复用
- 缓存 Key 建议设为
"nonce:" + sha256.Sum256([]byte(nonce)).Hex()，避免明文存储敏感值 - 缓存过期时间应略长于最大允许时间偏移（例如设为 360 秒），防止边界时间窗口内误判
HTTP Header 传 Nonce 比 Query 参数更安全
把 Nonce 放在 X-Nonce 或 X-Request-ID 这类自定义 Header 中，比塞进 URL Query 更可靠：
- Query 参数容易被代理、CDN、日志系统无意记录或泄露
- Header 默认不参与 GET 缓存键计算（而 Query 会），降低意外重放风险
- 配合签名时，Header 中的 Nonce 可自然纳入签名原文（如
method + path + timestamp + nonce + body_hash），保证整体防篡改 - 注意：若用 HTTP/2，Header 名称需小写（
x-nonce），Go 的http.Header会自动规范化，但下游中间件可能敏感
Redis 缓存失效不是万能的，要考虑分布式锁竞争
高并发下多个请求几乎同时携带新 Nonce 到达，可能触发缓存穿透式写入冲突。直接 SET key value EX 360 NX 是正确姿势，但要注意：
- 不要先
GET再SET—— 这之间有竞态窗口 - Go 客户端推荐用
redis.Client.SetNX(ctx, key, value, ttl)，返回true才代表首次注册成功 - 若
SetNX返回false，说明该 Nonce 已存在，直接拒掉请求（HTTP 401 或 409） - 别依赖 TTL 自动清理——极端情况下 Redis 崩溃重启后缓存全失，得靠时间戳校验兜底
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
