前端防重提交不能替代后端幂等，因网络超时、刷新、脚本或恶意请求可绕过；后端须通过唯一索引插入、乐观锁+状态机、Redis短时去重（key含业务维度）等手段保障幂等。
为什么前端防重提交不等于后端幂等
用户点击按钮后禁用、加 loading、拦截重复请求，这些前端手段只能减少重复提交概率，无法杜绝。网络超时重试、浏览器刷新、脚本误触发、恶意请求都会绕过前端控制。后端必须独立承担幂等性责任，否则数据库可能写入多条相同订单、扣款多次、库存超卖。
最常用：基于唯一业务 ID 的 insert 冲突检测
适用于创建类接口（如下单、发券、申请退款），核心是把 business_id（如订单号、流水号）设为数据库唯一索引。插入前不查、直接 insert，靠数据库约束拒绝重复。
- 避免先
SELECT再INSERT的竞态问题（两个并发请求都查不到，都插入成功） - MySQL 返回
ERROR 1062: Duplicate entry，PostgreSQL 返回ERROR: duplicate key value violates unique constraint，Go 中用pg.ErrCodeUniqueViolation或mysql.MySQLError类型断言捕获 - 业务逻辑需明确区分「插入成功」和「已存在」两种合法状态，返回一致的 HTTP 状态码（如
201 Created或200 OK），不能抛 500
_, err := db.Exec("INSERT INTO orders (order_id, user_id, amount) VALUES ($1, $2, $3)", orderID, userID, amount)
if err != nil {
var pgErr *pgconn.PgError
if errors.As(err, &pgErr) && pgErr.Code == "23505" { // unique_violation
// 订单已存在，查询并返回原记录
return getOrderByID(orderID)
}
return err
}
需要状态变更时：乐观锁 + 版本号 or 状态机校验
适用于修改类接口（如支付回调、审核通过、发货），不能只靠唯一键，因为同一笔订单可能被多次“支付成功”回调触发。
- 在表中增加
version字段（int）或status字段（enum），更新时带上前置条件 - 例如：只允许从
pending→paid，且version = ?；若RowsAffected == 0，说明已被处理过 - 不要用
UPDATE ... SET status = 'paid' WHERE order_id = ?这种无条件更新，它不具备幂等语义 - Redis 可辅助做短时幂等（如 5 分钟内相同
pay_notify_id拒绝二次处理），但不能替代 DB 层校验——Redis 故障或过期会导致漏判
全局幂等 Key 要带业务上下文，不能只用客户端传的 ID
有人用客户端生成的 request_id 作为 Redis key 做去重，这很危险。如果多个用户共用同一个 request_id（比如 SDK 复用、测试脚本硬编码），就会互相干扰。
立即学习“go语言免费学习笔记（深入）”；
- 幂等 key 必须包含业务维度，例如：
idempotent:pay:{user_id}:{order_id}:{notify_id} - key 过期时间要略长于最大业务处理耗时（比如 10 分钟），但不宜设成永不过期，防止 key 泄露堆积
- 注意 Redis 的
SET key value EX 600 NX原子操作：返回true才执行业务，false直接返回成功响应——但此时你得确保“返回成功”和“实际未执行”对业务是等价的（比如通知类接口可以这样，资金类不行）
