防重提交中间件必须基于服务端生成的唯一幂等键（如X-Idempotency-Key或user_id+path+body_hash）实现，禁用不可靠的客户端时间戳；需用Redis Lua脚本原子校验并设值，避免竞态；key过期时间应为业务最大耗时×2，且须覆盖多实例部署场景。
防重提交中间件在 Echo 中不能靠简单加锁或时间戳判断就完事——用户可能开多个标签页、网络延迟导致重复请求、或者前端没做按钮禁用，后端必须在「同一用户+同一操作意图」维度做幂等控制。关键不是“拦住所有重复”，而是“让重复提交不产生副作用”。
为什么不能只用 time.Now().Unix() 做客户端时间校验
客户端时间不可信，NTP 同步偏差、手动改系统时间、跨时区设备都会让时间戳失效。更严重的是，两次合法请求（比如用户快速双击提交）可能时间差极小但语义完全不同（如两次下单），仅靠时间窗口会误杀或漏放。
- 服务端必须依赖服务端生成的唯一标识，比如
X-Request-ID头或 JWT payload 里的jti（JWT ID） - 若前端无法带
jti，退而求其次用user_id + path + body_hash构造幂等 key，但注意 GET 请求无 body，需忽略 body_hash - 避免把整个 request body 当 key 存 Redis——大 body 会拖慢序列化和网络传输，应取 SHA256(body) 截前 16 字节作指纹
echo.MiddlewareFunc 实现幂等中间件的正确姿势
中间件必须在 next(c) 前完成校验并决定是否跳过执行，不能等 handler 返回后再处理——那样数据库写入已完成，补救成本高。
Echo框架 5.1.0
下载
Echo框架 5.1.0 版本源码包下载，适合关注 RealIP 行为变化、StartConfig.Listener、NewDefaultFS 和观测性中间件入口的开发团队。
- 从
c.Request().Header.Get("X-Idempotency-Key")或c.Request().URL.Query().Get("idempotency_key")提取 key；若缺失且业务强要求幂等（如支付），直接返回400 Bad Request - 用
redis.SetNX(ctx, "idemp:"+key, "processing", 30*time.Second)尝试占位；失败说明已存在，查该 key 对应的最终状态（成功/失败/进行中）并原样返回响应体 - 成功占位后执行
next(c)；handler 返回非nilerror 时，用 Lua 脚本原子更新 Redis 状态为failed；否则设为success并存下响应 body（限长 1KB） - 注意：不要在中间件里调
c.JSON()后还调next(c)，会导致响应头重复写入 panic
多实例部署下 Redis 的原子性陷阱
单纯用 SETNX + GET 两步走有竞态：A 实例 SETNX 成功，B 实例在 A 写状态前也 SETNX 成功（因 key 过期被删），结果两个请求都进业务逻辑。
立即学习“go语言免费学习笔记（深入）”；
- 必须用 Lua 脚本封装「检查是否存在 → 若不存在则设值并返回 ok → 若存在则取状态」整套逻辑，例如：
if redis.call("exists", KEYS[1]) == 1 then return redis.call("get", KEYS[1]) else redis.call("setex", KEYS[1], ARGV[1], "processing") return "new" end - Redis key 过期时间建议设为业务最大耗时 × 2（如下单接口最长 5s，则设 10s），太短易误判，太长占内存
- 别用本地内存（
sync.Map）存幂等状态——单机有效，集群下完全失效
真正难的不是写中间件函数，而是定义清楚「什么才算一次重复提交」：是同一用户对同一订单的二次支付？还是任意用户对同一商品的秒杀请求？key 的构造粒度一旦定错，后续所有缓存、日志、告警都会偏移。上线前务必用真实链路压测，观察 Redis key 分布和命中率。
