用 http.Header 获取 X-CSRF-Token 后，需原子验证其存在性、时效性与未使用性：先查 Redis 是否已存在该 Token（SetNX），若不存在或已过期则拒收；若存在则校验签名与过期时间，全部通过才允许业务处理，否则返回 409 或 422。
怎么用 http.Header 检查重复提交的 Token？
关键不是生成 Token，而是验证它是否已被消费。Golang 没有内置“一次性 Token”支持，得自己管状态——常见错误是只校验 X-CSRF-Token 是否存在或签名是否有效，却没检查它是否已用过。
真实场景里，用户快速连点两次“提交订单”，后一次请求可能在前一次还没写入 DB 时就进来了，所以验证必须原子、带时效、且和业务生命周期对齐。
- Token 建议用
uuid.NewString()生成，不要用时间戳或自增 ID - 存储选
sync.Map（单机）或 Redis（分布式），键为 Token，值为过期时间戳或结构体{used: bool, expires: int64} - 验证逻辑必须包含三步：是否存在 → 是否过期 → 是否已用；任一失败就拒掉，且不重试
- 别在
net/http中间件里直接return400，要确保响应头已写、body 已刷出，否则前端可能收不到错误
为什么 gorilla/sessions 不适合防重放？
它能存 Token，但默认 Session 存储（如 cookie store）不保证原子读-改-写，两个并发请求可能同时读到 used=false，都设成 true 后写回，结果变成“一次消费，两次通过”。
更麻烦的是，它的 Save() 是延迟写入，中间件里调 session.Save(r, w) 后，若后续 handler panic，Session 可能根本没落盘，导致 Token 被误判为未使用。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 如果坚持用
gorilla/sessions，必须搭配 Redis store，并开启Options{MaxAge: 0}避免客户端缓存旧值 - 绝对不要把 Token 存在
session.Values["token"]然后靠session.Save标记已用——这没有并发保护 - 正确做法是：Token 存 session 仅作下发，验证和标记消耗全走独立存储（如
redis.SetNX）
time.Now().UnixMilli() 做 Token 过期行不行？
不行。毫秒级时间戳可预测、无随机性，攻击者抓一个请求就能批量伪造有效 Token；而且它本身不含签名，无法防篡改。
真正需要的是“带签名 + 有时效 + 一次性”的组合。比如用 gob.Encoder 编码 struct{ID string; Expire int64}，再用 hmac.Sum256 签名，最后 base64 拼一起——但注意，签名密钥不能硬编码，得从环境变量或 KMS 加载。
- 过期时间建议设为 5–15 分钟，太短影响用户体验，太长增加重放窗口
- 别用
time.Now().Add(10 * time.Minute).Unix()直接塞进 Token，要签完再发，否则中间人可截获并延用 - 前端拿到 Token 后，应在表单隐藏域和请求头都传一份（防 CSRF+防重复），后端两边比对一致才继续
并发提交时 redis.SetNX 返回 false 怎么处理？
这是正常现象，说明 Token 已被另一个请求抢先消耗。此时不应重试、不生成新 Token、不跳转，而应明确返回 409 Conflict 或 422 Unprocessable Entity，并附带 {"error": "duplicate_submission"}。
很多开发者在这里加兜底逻辑：比如“若 SetNX 失败，就查下 DB 里这笔订单是否存在，存在就返回成功”，这反而破坏幂等性——DB 查到订单只能说明“上次提交成功了”，不能证明“这次提交也该算成功”，尤其涉及库存扣减、余额变动时，极易超卖。
- Redis key 的 TTL 必须略大于 Token 过期时间（比如多 2 秒），防止因时钟漂移导致提前失效
- 用
redis.Client.SetNX(ctx, token, "used", 10*time.Second)，value 写死字符串比结构体更轻量 - 务必检查
err是否为redis.Nil（表示未设置成功），而不是只看返回的bool
最易被忽略的一点：Token 的生成和消费必须绑定同一用户会话上下文。如果登录态靠 Cookie，但 Token 存在 Header 里，中间代理或 CDN 可能缓存响应，把 A 用户的 Token 泄露给 B 用户。所以生成 Token 的接口必须禁用缓存：w.Header().Set("Cache-Control", "no-store")。
