前端防重提交不等于后端幂等，因网络重试、F5刷新等可绕过前端直接触发多次请求；只要接口有副作用且可能被重复调用，就必须在服务端实现幂等，常用Redis+唯一token配合DB唯一索引兜底。
为什么前端防重提交不等于后端幂等
前端加按钮置灰、节流、拦截重复请求，只拦得住“善意用户”；网络超时重试、F5刷新、代理重放、脚本调用，都会绕过前端直接打到后端。所以 POST /order 接口被连发三次，订单仍可能创建三份——这不是前端没做好，是后端没做幂等控制。
关键判断：只要接口有副作用（写库、发消息、扣余额），且客户端可能重复触发，就必须在服务端落地幂等逻辑。
用 Redis + Token 实现最简可靠幂等
主流方案里，Redis SETNX 配合唯一业务 token 是平衡开发成本与可靠性的首选。流程是：前端先 GET /api/token 拿 token，再把 token 放在请求 header（如 X-Idempotency-Key）或 body 里提交；后端校验该 token 是否已存在，存在则拒绝，不存在则写入并执行业务逻辑。
-
SET key value EX 300 NX必须带NX（仅当 key 不存在才设值）和EX（过期时间，建议 5–10 分钟，覆盖最长业务链路耗时） - token 建议用
uuid.NewString()生成，不要用时间戳+随机数拼接——避免碰撞和可预测性 - 务必在事务最外层校验 token，不能等 DB 插入成功后再删 token；否则 DB 成功但 Redis 失败，下次请求会因 token 已存在而误拒
- 如果业务需要返回“重复提交”的明确提示，
SET返回0时应返回 HTTP 409，并附带{"code": "IDEMPOTENT_CONFLICT"}
DB 唯一索引兜底比应用层判断更安全
Redis 可能宕机、网络分区、或 set 成功但业务出错未清理，单靠它无法 100% 保证。真正可靠的幂等必须由数据库最终约束。
立即学习“go语言免费学习笔记（深入）”；
例如订单号字段，在 DB 表中加 UNIQUE INDEX，并在业务逻辑中捕获唯一键冲突错误：
_, err := db.Exec("INSERT INTO orders (order_no, user_id, amount) VALUES (?, ?, ?)", orderNo, uid, amt)
if err != nil {
if strings.Contains(err.Error(), "Duplicate entry") ||
mysql.IsDupEntryError(err) { // 使用 database/sql/driver 的标准判断
return handleIdempotentSuccess(orderNo)
}
return err
}
注意：UNIQUE 字段不能是自增 ID 或纯时间戳，必须是业务语义上天然唯一的标识，比如「用户ID + 业务类型 + 时间戳哈希」或外部传入的 client_order_id。
哪些场景不适合简单 Token 方案
Token 方案依赖“一次一用”，但以下情况需调整设计：
- 支付回调（如支付宝异步通知）：对方可能多次推送同一通知，且无 token 上下文 → 应用
message_id或notify_id做幂等键，配合 DB 唯一键 + 状态机判断（只允许从pending→success） - 分步操作（如“下单→支付→发货”）：整个流程需全局幂等，不能每步单独 token → 引入状态版本号（
state_version）或使用分布式锁 + 状态校验 - 高并发秒杀类接口：Redis 单点压力大 → 改用分片 token（如按 user_id % 16 分 16 个 key）或升级为 Redis Lua 脚本原子操作
真正的难点不在“怎么写一个幂等接口”，而在“怎么定义这个操作的幂等边界”——是单次请求？同用户同商品？还是同业务单据全生命周期？这个边界一旦定错，后面所有技术方案都白搭。
