引言：防重复提交的必要性

在互联网应用中，用户操作习惯与网络环境的不确定性，常导致接口被重复调用。例如：用户快速点击提交按钮、网络延迟引发的重试、恶意刷单行为等，均可能引发数据不一致、业务逻辑错误甚至系统崩溃。接口防抖（防重复提交）技术通过限制单位时间内接口调用次数，成为保障系统稳定性的关键手段。

一、前端按钮级防抖：基础防护层

1.1 按钮禁用与状态管理

前端防抖的核心是阻止用户短时间内重复触发请求。以React为例，可通过状态管理实现按钮禁用：

function SubmitButton() {
  const [isSubmitting, setIsSubmitting] = useState(false);
  const handleSubmit = async () => {
    if (isSubmitting) return;
    setIsSubmitting(true);
    try {
      await fetch('/api/submit', { method: 'POST' });
    } finally {
      setIsSubmitting(false);
    }
  };
  return (
    <button onClick={handleSubmit} disabled={isSubmitting}>
      {isSubmitting ? '提交中...' : '提交'}
    </button>
  );
}

适用场景：单页面应用（SPA）中的表单提交，适合对用户体验要求较高的场景。
局限性：依赖前端代码，无法防御恶意绕过（如直接调用API）。

1.2 防抖函数库的应用

Lodash等工具库提供的_.debounce函数可封装请求逻辑：

import { debounce } from 'lodash';
const debouncedSubmit = debounce(async () => {
  await fetch('/api/submit', { method: 'POST' });
}, 1000); // 1秒内仅执行一次
// 绑定到按钮点击事件

优势：代码简洁，可复用性强。
注意点：需合理设置防抖时间窗口，过长影响用户体验，过短失去防护意义。

二、后端Token校验：安全增强层

2.1 一次性Token机制

后端生成唯一Token并返回前端，提交时校验Token有效性：

// 后端生成Token
@GetMapping("/getToken")
public String getToken(HttpServletRequest request) {
  String token = UUID.randomUUID().toString();
  request.getSession().setAttribute("submitToken", token);
  return token;
}
// 提交时校验
@PostMapping("/submit")
public ResponseEntity<?> submit(
    @RequestParam String token,
    HttpSession session) {
  String sessionToken = (String) session.getAttribute("submitToken");
  if (token == null || !token.equals(sessionToken)) {
    return ResponseEntity.badRequest().body("重复提交");
  }
  session.removeAttribute("submitToken"); // 销毁Token
  // 处理业务逻辑
}

优势：跨页面有效，防御CSRF攻击。
变体：可结合Redis实现分布式Token存储，支持集群环境。

2.2 请求参数签名

对请求参数进行加密签名，后端校验签名唯一性：

// 前端生成签名
const params = { userId: 123, amount: 100 };
const signature = CryptoJS.HmacSHA256(
  JSON.stringify(params), 
  'SECRET_KEY'
).toString();
// 后端校验
app.post('/api/pay', (req, res) => {
  const { params, signature } = req.body;
  const expectedSig = crypto.createHmac('sha256', 'SECRET_KEY')
    .update(JSON.stringify(params))
    .digest('hex');
  if (signature !== expectedSig) {
    return res.status(400).send('无效请求');
  }
  // 处理业务
});

适用场景：金融交易等高安全要求场景。

三、分布式锁：高并发防护

3.1 Redis实现分布式锁

使用Redis的SETNX命令实现锁机制：

// 加锁
public boolean tryLock(String key, String requestId, int expireTime) {
  String result = jedis.set(key, requestId, "NX", "EX", expireTime);
  return "OK".equals(result);
}
// 业务处理前加锁
if (tryLock("submit_lock_" + userId, UUID.randomUUID().toString(), 10)) {
  try {
    // 执行业务逻辑
  } finally {
    // 解锁（需校验requestId防止误删）
    String script = "if redis.call('get', KEYS[1]) == ARGV[1] then " +
                   "return redis.call('del', KEYS[1]) " +
                   "else return 0 end";
    jedis.eval(script, Collections.singletonList(key), 
              Collections.singletonList(requestId));
  }
} else {
  throw new RuntimeException("操作频繁，请稍后再试");
}

关键点：

• 锁需设置过期时间，防止死锁
• 解锁时校验requestId，避免误删其他请求的锁
• 推荐使用Redisson等成熟框架简化实现

3.2 数据库唯一约束

通过数据库唯一索引防止重复数据：

CREATE TABLE orders (
  id BIGINT PRIMARY KEY,
  user_id BIGINT NOT NULL,
  order_no VARCHAR(32) NOT NULL UNIQUE,
  -- 其他字段
);

业务逻辑：

try {
  orderRepository.save(new Order(userId, generateOrderNo()));
} catch (DataIntegrityViolationException e) {
  throw new BusinessException("请勿重复提交");
}

优势：实现简单，数据强一致。
注意点：需处理异常并返回友好提示。

四、消息队列削峰：异步处理方案

4.1 RabbitMQ延迟队列

将请求先投入延迟队列，超时后消费：

# 生产者
channel.basic_publish(
  exchange='',
  routing_key='submit_queue',
  body=json.dumps(request_data),
  properties=pika.BasicProperties(
    delivery_mode=2,  # 持久化
    expiration='5000'  # 5秒后过期
  )
)
# 消费者
def callback(ch, method, properties, body):
  # 查询是否已处理（需额外存储处理状态）
  if not is_processed(body):
    process_request(body)
    mark_as_processed(body)

适用场景：允许异步处理的非实时业务。

4.2 Kafka消息去重

利用Kafka的事务性生产者实现精确一次语义：

producer.initTransactions();
try {
  producer.beginTransaction();
  producer.send(new ProducerRecord<>("topic", key, value));
  // 更新数据库状态
  producer.commitTransaction();
} catch (Exception e) {
  producer.abortTransaction();
}

关键配置：

• enable.idempotence=true 启用幂等生产
• transactional.id 配置唯一事务ID

五、综合防护策略建议

1. 分层防御：前端防抖（用户体验）+ 后端Token（基础防护）+ 分布式锁（高并发）
2. 幂等设计：所有接口需支持幂等调用，如通过订单号去重
3. 监控告警：对重复提交请求进行日志记录与异常告警
4. 降级方案：高并发时自动切换至队列处理模式

六、典型场景解决方案

场景	推荐方案	防护强度
电商下单	Token校验 + 数据库唯一约束	高
金融转账	分布式锁 + 消息队列	极高
表单提交	前端防抖 + Token校验	中
物联网设备上报	请求签名 + Redis计数器	中高

结语

接口防抖需结合业务特点选择技术方案。对于核心业务，建议采用”前端防抖+后端Token+分布式锁”的三重防护；对于非关键路径，可简化实现。实际开发中，应通过压力测试验证防抖策略的有效性，并持续优化参数配置。