Revel框架需自建防重放中间件：在init()注册Filter，校验timestamp窗口与nonce唯一性，用userId+method+参数摘要构造Redis锁key，确保校验在DB事务前完成且原子执行。
Revel 框架本身不内置防重放（replay attack）或表单重复提交的完整机制，它只提供基础的请求生命周期钩子和中间件能力。你要实现可靠防重，必须自己补全关键链路：**时间戳+随机 nonce + 服务端校验缓存**。单纯依赖前端禁用按钮、隐藏域 token 或客户端时间校验，在 Revel 中是无效且可绕过的。
怎么在 Revel 中加防重放中间件？
Revel 的中间件模型基于 Filter 链，你需要在 app/init.go 的 init() 函数中注册一个自定义 Filter，拦截所有写操作（如 POST、PUT、DELETE）。
核心逻辑包括：
- 从请求头（推荐）或 JSON body 中提取
timestamp和nonce - 检查
timestamp是否落在允许窗口内（例如 ±5 分钟），否则拒绝 - 用
nonce + userId（或 session ID）构造唯一 key，查 Redis（或本地 LRU cache，仅限单机）是否已存在；存在则为重放，返回400 Bad Request - 校验通过后，将该
nonce写入缓存并设置过期时间（略长于时间窗口，如 6 分钟）
注意：nonce 必须一次性使用，且不能跨用户共享——否则 A 用户的合法 nonce 可被 B 用户复用。若用 session ID 做拼接，需确保 session 已生成且可信（即登录态已验证）。
Revel 表单重复提交：为什么不能只靠 template hidden input？
Revel 的模板系统支持 {{.XSRFToken}}，但它只是 CSRF 防护，**不是防重提交 token**。你如果手动在 form 里塞 <input type="hidden" name="token" value="{{.SubmitToken}}">，然后在 controller 里用 c.Params.Get("token") 校验并删除，会立刻踩两个坑：
- HTTP 请求 body 只能读一次，
c.Params.Get对 JSON body 不生效，必须提前用c.Request.Body解析并缓存；否则后续业务逻辑再读就空了 - 没有绑定请求上下文粒度（如 URL + 用户 + 参数摘要），同一个 token 提交两次不同表单（比如改密码和绑手机）也会冲突或漏判
正确做法是：在中间件里统一解析 body → 提取稳定参数（如 email、orderNo）→ 计算 SHA256 → 拼上 userId 和 method 构成锁 key → 走 SET NX EX 加分布式锁。失败直接 c.Result = abort(409)。
Redis 锁 key 设计容易忽略的细节
很多人用 "repeat:" + c.Request.RemoteAddr + c.Request.URL.Path 作为锁 key，这在 Revel 里会导致严重误杀：
- 同一 IP 下多个用户（如公司 NAT、校园网）会被锁死
- URL 带分页参数或临时 query（如
?t=123）会使相同业务请求产生不同 key - 没包含用户标识，未登录场景无法区分，已登录却用了 session ID 而非 user ID，登出后残留 key 无法清理
推荐结构："repeat:submit:" + userId + ":" + method + ":" + hex.EncodeToString(sha256.Sum256([]byte(stableParams)).[:8])，其中 stableParams 是按 key 字典序拼接的业务关键字段（排除 timestamp、nonce、sign 等动态值）。key 过期时间设为 2–5 秒足够，太长会阻塞正常重试。
最常被跳过的一步：没把防重逻辑放在事务外。Revel 的 DB 操作常在 controller 里显式开启 tx.Begin()，但 Redis 校验必须在事务开始前完成——否则校验通过后、事务提交前崩溃，锁释放了，但数据没写入，下次请求仍会通过校验并重复执行。顺序只能是：校验 → 加锁 → 开事务 → 执行 → 删锁（用 Lua 保证原子性）。
