前端防重提交不能替代后端幂等，因网络超时、刷新、脚本或恶意请求可绕过；后端须通过唯一索引插入、乐观锁+状态机、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 复用、测试脚本硬编码），就会互相干扰。

• 幂等 key 必须包含业务维度，例如：idempotent:pay:{user_id}:{order_id}:{notify_id}
• key 过期时间要略长于最大业务处理耗时（比如 10 分钟），但不宜设成永不过期，防止 key 泄露堆积
• 注意 Redis 的 SET key value EX 600 NX 原子操作：返回 true 才执行业务，false 直接返回成功响应——但此时你得确保“返回成功”和“实际未执行”对业务是等价的（比如通知类接口可以这样，资金类不行）