前端防重提交不能替代后端幂等校验，因仅防手抖，无法应对脚本调用、超时重试等真实重复场景；后端须用request_id+Redis原子操作或数据库唯一约束实现可靠幂等。
为什么前端防重提交不能替代后端幂等校验
用户点击按钮后禁用、加 loading、拦截重复请求，这些前端手段只防“手抖”，挡不住脚本批量调用、网络超时重试、F5 刷新重发。真正的重复提交一定发生在服务端——比如支付接口被 Nginx 重试两次、客户端因超时主动重发、消息队列重复投递。所以 前端限制是体验层，后端幂等是可靠性底线。
用请求唯一标识（request_id）+ Redis 缓存实现简单幂等
核心思路：每个请求带一个客户端生成的 request_id（如 UUID），服务端在业务逻辑执行前先查 Redis 是否已存在该 ID；存在则直接返回上次结果（或空响应），不存在则写入并继续处理。
实操要点：
-
request_id必须由客户端生成并透传（避免服务端生成导致重试时 ID 变化） - Redis key 建议用
"reqid:" + request_id，过期时间设为业务最大处理耗时的 2–3 倍（如支付接口设 10 分钟） - 写入 Redis 要用
SET key value EX seconds NX原子操作，防止并发写入冲突 - 成功写入后才执行业务逻辑；若失败需回滚 Redis 写入（但实际中更推荐“写入即承诺”，失败也保留记录并返回错误）
示例伪代码：
立即学习“go语言免费学习笔记（深入）”；
if !redis.SetNX(ctx, "reqid:"+req.Header.Get("X-Request-ID"), "processing", 600*time.Second) {
// 已存在，查历史结果或直接返回 409 Conflict
return
}
// 执行业务逻辑
result := doPayment(req)
redis.Set(ctx, "reqid:"+req.Header.Get("X-Request-ID"), result, 600*time.Second)
数据库唯一约束比 Redis 更可靠，但适用场景有限
对创建类操作（如订单、退款单），直接在 DB 表加联合唯一索引（如 user_id + biz_no 或 request_id 字段）是最强兜底。即使 Redis 挂了、缓存穿透、或并发极高，DB 层仍能靠唯一键拒绝重复插入。
注意点：
- 必须捕获
ERROR 1062 (23000): Duplicate entry类错误，并转换为业务友好的响应（如 “该操作已处理”） - 不能依赖事务自动回滚来“假装没发生”——重复插入失败本身就要被感知和响应
- 不适用于更新类操作（如“扣余额”），因为 UPDATE 不触发唯一约束，需配合状态机或版本号
GET 请求天然幂等，但 POST/PUT/PATCH 都要默认视为非幂等
HTTP 规范里只有 GET、HEAD、OPTIONS、TRACE 是安全且幂等的；POST 明确是非幂等的（RFC 7231）。别因为“这个接口只是改个状态”就跳过幂等设计——只要它接受外部触发、影响数据或产生副作用，就必须考虑重试、代理重发、浏览器刷新带来的重复。
特别提醒：curl -X POST 测试时反复敲回车、Postman 点多次、Nginx proxy_next_upstream error timeout 配置，都会真实触发重复提交。线上出问题从来不是“理论上不会”，而是“刚好撞上了”。
