Revel框架需自行实现防重复提交，须在首个filter中用io.TeeReader+bytes.Buffer包装可重读body并赋值c.Request；配合revel.Interceptor与Redis SET NX原子操作，基于URL、Header及规范序列化请求体生成签名key进行短时幂等校验。
Revel 框架本身不内置防重复提交机制，必须自行组合中间件、请求签名、Redis 缓存与唯一键校验来实现。纯靠前端按钮禁用或客户端时间戳拦截，在分布式、重试、爬虫或调试绕过场景下完全不可信。
Revel 中间件如何拦截并包装可重读的 http.Request
Revel 的 Filter 链中，http.Request.Body 默认是单次读取流，一旦被 controller 解析（如 c.Params.Bind 或 JSON 解析），后续无法再读取用于生成防重签名。必须在第一个 filter 里就用 io.TeeReader + bytes.Buffer 包装原始 body，并替换为可重读的 io.ReadCloser。
常见错误是：在 filter 中只做日志打印或简单 header 检查，没提前缓存 body；结果到防重逻辑时 r.Body 已 EOF，签名始终为空或出错。
- 必须在
app.Init注册的 filter 链中，排在所有业务 filter 之前（如位置 0 或 1） - 包装后需将新
*http.Request赋值给c.Request，否则 controller 仍用原始 request - 注意不要对文件上传（
multipart/form-data）盲目缓存整个 body，容易 OOM；应按 content-type 分流处理
如何用 revel.Interceptor + Redis 实现短时幂等校验
Revel 的拦截器（revel.Interceptor）比全局 filter 更精准，适合按 action 方法打标。推荐配合自定义注解（如 @Idempotent(seconds = 60)）和 Redis 的 SET key value EX 60 NX 原子操作实现“占坑式”校验。
关键点不是存什么，而是怎么判重：不能只比对 URL 和 method，必须包含签名化的请求体（如 SHA256(r.URL.Path + r.Header.Get("X-User-ID") + bodyBytes)）作为 key，否则同一用户连续提交不同数据也会被误拦。
-
SET成功表示首次请求，继续执行；失败说明 key 已存在，直接返回425 Too Early或自定义错误码 - Redis key 过期时间（
EX）要略大于接口平均耗时（如设为 90 秒），避免因慢请求导致误判 - 不要在拦截器里手动
DELkey——万一业务 panic 或超时，key 残留会导致后续合法请求被拒；应依赖 TTL 自动清理
revel.Params 和 c.Params.Bind 对防重签名的影响
Revel 的参数绑定（c.Params.Bind）会自动解析 query、form、JSON，但这个过程发生在 filter 链之后、action 执行之前。如果你在 filter 里只读了 raw body，但没同步更新 c.Params，那么后续 c.Params.Get 取到的可能是空或旧值，导致签名与实际业务参数不一致。
更隐蔽的问题是：当请求含 application/x-www-form-urlencoded 且含中文或特殊字符时，c.Params 默认使用 UTF-8 解码，而你从 raw body 直接读取的是字节流，若未统一编码再哈希，签名必然不匹配。
- 建议统一在 filter 中完成 body 解析，并把结构化参数（map[string]interface{}）序列化为规范 JSON 后参与签名，避开编码歧义
- 避免在多个地方重复解析 body：filter 解一次，action 里不要再调
c.Params.Bind，改用已解析好的上下文变量 - 若必须用
c.Params.Bind，确保它和防重签名使用同一套解析逻辑（例如都走json.Unmarshal），否则字段顺序、空值处理差异都会让签名失效
真正难的不是写一个能跑通的防重逻辑，而是让签名在所有 content-type、所有编码、所有参数来源（query/form/json）下保持稳定且不可绕过。线上最常崩的点，永远是那个没测到的 multipart/form-data 文件上传 + 文本字段混合场景，或者某个前端 SDK 自动加了 X-Requested-With 导致签名 key 突然变化。这些细节不压到每个请求路径里验证，上线后只能靠报警和回滚救火。
