你是否遇到过这样的情况：用户疯狂点击提交按钮导致订单重复创建，支付系统因网络延迟重复扣款，表单提交后刷新页面造成数据混乱？这些令人头疼的问题，其实都可以通过合理的后端接口设计来解决。今天就为大家分享5个经过大厂验证的防重复提交技巧，让你的系统从此稳如磐石！

一、重复提交有多可怕？真实案例警示

某电商平台在一次促销活动中，由于未做防重复提交处理，导致用户在网络延迟情况下多次点击下单按钮，系统瞬间生成了上万条重复订单，库存被错误扣减，最终不得不紧急下架商品并赔偿用户损失，直接经济损失超过百万。

另一支付系统因接口幂等性设计缺陷，在第三方回调重试机制下，同一笔交易被重复扣款，引发大量用户投诉，不仅影响了公司声誉，还产生了巨额的退款成本。

这些血淋淋的教训告诉我们：防重复提交不是可有可无的功能，而是后端系统必须具备的基础防护能力。

二、5个实战技巧，层层防护

1. Token令牌机制：给请求发一张"一次性门票"

想象一下，当你去看演唱会时，门票一旦撕毁就无法再次使用。Token机制的原理与此类似，它为每个请求生成一张"一次性门票"。

实现步骤：

1. 用户访问表单页面时，后端生成一个唯一的Token（类似UUID）并存储在Session或Redis中

2. 将Token通过隐藏表单域或请求头返回给前端

3. 用户提交请求时必须携带这个Token

4. 后端验证Token有效性后立即删除，确保只能使用一次

Token机制流程图

代码示例：

// java// 生成TokenString token = UUID.randomUUID().toString();request.getSession().setAttribute("token", token);// 验证TokenString clientToken = request.getParameter("token");String serverToken = (String) request.getSession().getAttribute("token");if (clientToken == null || !clientToken.equals(serverToken)) {return "请勿重复提交";}request.getSession().removeAttribute("token"); // 立即失效

适用场景：用户注册、表单提交、评论发布等需要用户主动操作的场景。

2. 数据库唯一约束：给数据加一把"安全锁"

数据库唯一约束就像是给你的数据加上了"身份证"，确保每条记录都是独一无二的。当重复请求过来时，数据库会像保安一样拒绝"冒名顶替者"。

实现方式：

o 对业务唯一字段添加唯一索引

o 捕获数据库抛出的DuplicateKeyException异常

数据库唯一索引示意图

SQL示例：

// sql-- 对订单号添加唯一索引ALTER TABLE orders ADD UNIQUE KEY uniq_order_no (order_no);

异常处理：

// javatry {orderMapper.insert(order);} catch (DuplicateKeyException e) {logger.error("订单已存在:{}", order.getOrderNo());return "订单提交成功"; // 对用户隐藏重复提交的细节}

注意事项：在高并发场景下，建议配合缓存使用，减轻数据库压力。

3. Redis分布式锁：分布式系统的"交通信号灯"

在分布式系统中，多台服务器就像多个路口，需要一个统一的"交通信号灯"来指挥流量。Redis分布式锁就是这样的信号灯，确保同一时间只有一个请求能处理关键业务。

实现原理：

o 使用Redis的SETNX命令（SET if Not Exists）实现分布式锁

o 设置合理的过期时间，避免死锁

o 使用Lua脚本保证释放锁的原子性

Redis分布式锁时序图

代码示例：

// javaString lockKey = "order:lock:" + orderId;// 尝试获取锁，设置30秒过期Boolean locked = redisTemplate.opsForValue().setIfAbsent(lockKey, "1", 30, TimeUnit.SECONDS);if (Boolean.TRUE.equals(locked)) {try {// 处理订单逻辑return processOrder(orderId);} finally {// 释放锁redisTemplate.delete(lockKey);}} else {return "系统繁忙，请稍后再试";}

最佳实践：推荐使用Redisson框架，它提供了自动续期、公平锁等高级特性，让分布式锁实现更简单可靠。

4. 幂等性设计：让重复请求变得"无害"

幂等性就像数学中的加法运算，1+1=2，无论你算多少次结果都一样。设计幂等性接口，就是让重复请求对系统的影响和单次请求完全相同。

核心思想：

o 每个请求必须包含唯一业务ID（如订单号、交易流水号）

o 服务端根据业务ID判断请求是否已处理

o 已处理的请求直接返回上次结果，未处理的则正常处理

幂等性设计流程图

案例解析：支付宝的支付接口就是典型的幂等性设计，无论你调用多少次同一笔交易的支付接口，用户账户只会被扣一次款。

实现示例：

// java@Transactionalpublic OrderDTO createOrder(OrderCreateDTO request) {// 检查订单是否已处理if (orderRepository.existsByOrderNo(request.getOrderNo())) {// 返回已存在的订单信息return orderConverter.toDto(orderRepository.findByOrderNo(request.getOrderNo()));}// 处理新订单Order order = new Order();order.setOrderNo(request.getOrderNo());order.setUserId(request.getUserId());order.setAmount(request.getAmount());// ...其他订单信息return orderConverter.toDto(orderRepository.save(order));}

5. 乐观锁：高并发下的"和平共处"之道

乐观锁就像交通规则，它假设大家都会遵守规则，只有在发现违规时才进行干预。通过版本号控制，乐观锁能在高并发场景下实现无锁化的并发控制。

实现原理：

o 在数据表中添加version字段

o 更新数据时校验版本号

o 版本号不匹配则更新失败

乐观锁版本控制流程图

SQL示例：

// sql-- 带版本号的库存扣减UPDATE productsSET stock = stock - 1, version = version + 1WHERE id = 100 AND version = 5;

代码处理：

// javaint rows = productMapper.decreaseStock(id, version);if (rows == 0) {// 更新失败，说明版本号已变化，可能需要重试throw new OptimisticLockException("数据已更新，请重试");}

适用场景：库存扣减、积分更新、状态变更等高频更新操作。

三、大厂都是怎么做的？实战案例分享

美团订单系统：

美团采用"预生成订单号+Redis分布式锁+数据库唯一约束"的多层防御策略。当用户进入下单页面时，前端就会请求生成唯一订单号，提交时通过Redis锁防止并发处理，最后由数据库唯一约束作为最终防线。

支付宝接口：

支付宝所有支付接口都要求传递唯一的outtradeno（商户订单号），通过幂等性设计确保重复请求不会重复扣款。即使由于网络原因导致商户重复调用接口，支付宝也只会处理一次交易。

电商秒杀系统：

秒杀场景是防重复提交的极端考验。大型电商平台通常采用"前端限流+Redis预扣减+消息队列异步处理+数据库最终校验"的全链路防护，既保证了性能，又确保了数据一致性。

四、技术选型决策指南

五、总结与建议

防止重复提交不是单一技术问题，而是系统设计层面的综合性挑战。在实际开发中，我建议：

1. 多层防御：不要依赖单一方案，前端限流+后端验证+数据库约束的多层防护才更可靠

2. 日志监控：对重复提交事件进行详细日志记录，便于问题排查和系统优化

3. 用户体验：重复提交时给予友好提示，避免简单粗暴地返回错误

4. 性能平衡：根据业务并发量选择合适方案，避免过度设计

最后记住：最好的防重复提交方案，是让用户感觉不到它的存在。通过合理的技术选型和优雅的实现，既能保证系统稳定，又不影响用户体验，这才是后端工程师的最高境界。

希望本文介绍的5个技巧能帮助你构建更健壮的后端系统，如果你有其他好的实践经验，欢迎在评论区分享！