重试请求必须重新签名，因为时间戳超窗或nonce已被redis标记重复，导致验签失败；客户端需每次重试时实时生成timestamp、新nonce并重算hmac签名，gin中间件不自动识别重试，所有请求均强制执行完整验签流程。
重试请求为什么必须重新签名
客户端重试时如果复用原始签名，服务端验签会失败——不是因为网络问题，而是时间戳已超窗或 nonce 已被 Redis 标记为重复。Gin 中的中间件无法自动识别“这是重试”，更不会帮你重算 signature、timestamp、nonce。常见错误是前端在 axios 里配了 retry: 3 却没同步刷新签名三要素，结果重试全被 401 拦截。
必须让每次重试都走完整签名流程：
- timestamp 用 time.Now().UnixMilli() 实时生成
- nonce 每次调用 crypto/rand.Read() 生成新 16 字节再 hex 编码
- signature 基于新拼接字符串（method|path|body|timestamp|nonce）重新计算 HMAC
Gin 中间件如何区分首次请求与重试
HTTP 协议本身不带“是否重试”元信息，但你可以约定一个轻量标识：在请求头加 X-Retry-Count，由客户端自增。Gin 中间件不解析这个头做逻辑分支，而是用它辅助日志和限流——比如 X-Retry-Count: 2 的请求，若签名失败，说明客户端没重签，直接返回 400 而非 401，避免暴露验签细节。
Colly 是一个用于 Go 语言的快速开源爬取和爬虫框架。它适用于从简单的页面提取到异步爬虫处理大量页面集合，支持请求回调和结构化解析。
关键点：
- 不依赖 X-Retry-Count 决定是否验签，它只是可观测信号
- 所有请求（无论是否重试）都强制执行完整验签流程
- 若发现 timestamp 距当前 >15000ms 或 nonce 已存在 Redis，则统一返回 401，不区分原因
Body 读取与重试的冲突怎么解
Gin 默认把 c.Request.Body 当作一次性流，重试前若已读过一次（比如中间件里 io.ReadAll(c.Request.Body)），第二次读就为空，导致签名原文里的 body 字段为空串，签名必然错。这不是 Gin bug，是 HTTP Body 的底层特性。
解决方案只有两个：
- 在中间件开头用 c.Request.Body = io.NopCloser(bytes.NewBuffer(bodyBytes)) 把 body 缓存回写，后续 handler 还能正常 c.ShouldBindJSON()
- 更推荐用 c.GetRawData()（Gin v1.9+）一次性读取并复用字节切片，避免两次读取
- 绝对不要在多个地方分别 ReadAll，尤其别在日志中间件和验签中间件里各读一次
重试场景下 Redis nonce 去重的坑
重试请求的 nonce 必须全新，但服务端不能因“同一用户短时间内发了 3 个不同 nonce”就拒绝后两次——这会误杀合法重试。Redis key 设计要带上下文：
- 错误做法：SET nonce:{nonce} 1 EX 20 → 3 个重试请求用 3 个不同 nonce，全通过，失去防重放意义
- 正确做法：SET retry:uid123:{timestamp} {nonce} EX 20 NX → 同一用户 + 同一毫秒级时间戳只允许一个 nonce，既允许多次重试，又防同一时间戳下的批量伪造
注意：
- timestamp 必须用毫秒级且参与签名，否则攻击者可固定 timestamp + 换 nonce 碰撞
- Redis SET ... NX 返回 redis.Nil 表示写入成功（首次出现），非 nil 表示已被占用，此时应拒掉该请求
- 不要用 INCR 或 GETSET，它们不具备原子性，高并发下会漏判
重试机制和防篡改不是叠加关系，而是耦合关系——签名字段的时效性决定了重试必须带新签名，而重试的存在又反过来要求 nonce 去重逻辑必须容忍合理范围内的重复提交。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
