SpringBoot 接口防抖实战：防重复提交的 5 种高级方案

作为一名摸爬滚打八年的 Java 开发，我敢说：线上 80% 的 “数据错乱” 故障，都和接口重复提交有关。上周大促，用户疯狂点击下单按钮，导致同一订单被创建了 3 次；去年支付接口被爬虫高频调用，直接产生了双倍扣款 —— 这些血淋淋的案例告诉我们：接口防抖不是 “可选功能”，而是 “必做防护”。

很多人觉得 “防重复提交不就是前端按钮禁用吗？”—— 太天真了！爬虫、Postman 直接调用、网络延迟重发，这些场景前端防护形同虚设。今天就从实战出发，分享 5 种 SpringBoot 接口防抖的高级方案，覆盖单机、分布式、高并发等所有场景，每一种都附可直接复制的代码和八年踩坑总结，让你彻底解决 “手抖党” 和 “恶意刷接口” 的烦恼。

一、先分清：防抖 vs 防重？别再混淆了！

在讲方案前，先澄清两个高频混淆的概念（八年开发见过太多人用错）：

• 接口防抖（Debounce） ：阻止短时间内重复触发同一接口（比如 1 秒内点 5 次下单），核心是 “限制触发频率”；
• 接口防重（Idempotent） ：保证同一请求多次执行结果一致（比如重复支付只扣一次钱），核心是 “结果唯一性”。

本文的方案是 “防抖 + 防重” 结合 —— 既阻止高频重复调用，又保证即使调用多次也不会出问题，真正做到 “双重防护”。

二、5 种高级方案：从单机到分布式，覆盖所有场景

方案 1：基于 Redis+Lua 脚本（分布式高并发首选）

核心原理

利用 Redis 的原子性 + Lua 脚本，给接口加 “限时锁”：同一请求标识（比如用户 ID + 接口名 + 参数摘要）在指定时间内只能执行一次，超过时间自动释放锁。

为什么用 Lua？

Redis 单条命令是原子的，但多条命令组合（比如先查 key 是否存在，再 set 值）会有并发问题。Lua 脚本能把多步操作打包成原子执行，避免 “竞态条件”—— 这是分布式防重的关键（八年开发踩过的坑：以前用 Redis+Java 代码判断，高并发下还是会出现重复提交）。

实战代码

1. 先定义防抖注解（标记需要防重的接口）

2. Lua 脚本（原子执行 “查锁 + 加锁”）在resources/lua/anti_duplicate_submit.lua创建脚本：

3. AOP 切面（拦截注解，执行 Lua 脚本）

4. 接口使用（只需加注解）

八年踩坑提示

• 过期时间别设太短（比如小于 500ms）：网络延迟可能导致正常请求被误判；也别设太长（比如超过 10 秒）：用户正常重试会被拦截；
• 请求标识必须包含 “用户 ID”：否则不同用户调用同一接口会被误判为重复；
• 非幂等接口（比如退款）建议执行完手动释放锁：避免正常流程结束后还占用锁。

适用场景：分布式系统、高并发场景（电商大促、支付接口）

方案 2：基于 Token 令牌（前后端联动，最安全）

核心原理

前端请求接口前，先向服务端申请 “唯一令牌”，服务端生成令牌存入 Redis；前端带着令牌调用业务接口，服务端验证令牌存在后执行逻辑，并删除令牌（确保只能用一次）。

为什么安全？

令牌是一次性的，且绑定用户，即使接口被爬虫抓取，没有令牌也无法重复提交 —— 这是防御 “恶意刷接口” 的终极方案。

实战代码

1. Token 生成接口（前端先调用获取令牌）

2. 令牌验证切面（可复用方案 1 的注解，新增验证逻辑）

3. 前端调用流程（伪代码）

八年踩坑提示

• 令牌过期时间要合理：太短（比如 1 分钟）用户操作慢会失效，太长（比如 30 分钟）占用 Redis 内存；
• 前端要处理令牌失效：如果调用业务接口时提示令牌过期，需重新获取令牌再重试；
• 建议和方案 1 结合：令牌验证 + Redis 限时锁，双重防护更稳妥。

适用场景：支付接口、退款接口等核心敏感接口

方案 3：基于本地缓存（Caffeine）（单机高并发首选）

核心原理

如果是单机部署的应用，没必要用 Redis，直接用本地缓存（Caffeine）存储请求标识，效率更高（本地缓存响应时间微秒级）。

为什么用 Caffeine？

Caffeine 是 Java 领域性能最好的本地缓存，支持过期时间、最大容量限制，比 HashMap + 定时任务更优雅，比 Guava Cache 性能高 5-10 倍。

实战代码

1. 引入 Caffeine 依赖（SpringBoot 3.x）

2. 配置 Caffeine 缓存

3. 改造切面（用本地缓存替代 Redis）

八年踩坑提示

• 必须设置最大容量：避免恶意请求导致缓存无限增长，引发 OOM；
• 仅适用于单机部署：多实例部署会出现缓存不一致，导致重复提交；
• 过期时间要短：本地缓存不支持分布式过期，太长会占用内存。

适用场景：单机部署、高并发读少写多的接口（比如查询 + 提交类接口）

方案 4：基于数据库唯一索引（兜底方案，最可靠）

核心原理

无论前端、缓存层防护得多好，数据库层都要加 “最后一道防线”—— 给核心业务字段建唯一索引（比如订单号、用户 ID + 商品 ID），即使重复提交，数据库也会抛出唯一约束异常，避免数据错乱。

为什么是兜底？

缓存可能失效，令牌可能被绕过，但数据库唯一索引是 “物理防护”，除非删索引，否则绝对不会出现重复数据 —— 八年开发的底线：核心业务必须加唯一索引！

实战代码

1. 数据库表设计（以订单表为例）

2. 业务代码处理唯一约束异常

八年踩坑提示

• 唯一索引要贴合业务：别盲目建唯一索引，比如 “用户 ID + 商品 ID” 适合 “限购一件” 的场景，“订单号” 适合所有订单唯一的场景；
• 避免过度建索引：索引会影响插入性能，核心字段才需要；
• 异常信息要脱敏：别把数据库表结构、字段名暴露给前端。

适用场景：所有核心业务接口（支付、下单、退款），作为兜底方案

方案 5：基于 AOP + 自定义注解（优雅封装，复用性强）

核心原理

把方案 1-4 的逻辑封装成通用注解，业务接口只需加注解即可实现防抖，无需写重复代码 —— 这是八年开发的 “偷懒技巧”：一次封装，处处复用。

进阶封装：支持多场景切换

改造切面：根据注解模式选择防抖方案

接口使用示例（按需选择模式）

适用场景：全场景复用，大型项目推荐（减少重复开发）

三、八年踩坑总结：3 个致命错误别犯！

1. 只做前端防抖，不做后端防护：前端按钮禁用能防 “手抖”，但防不住爬虫、Postman 直接调用 —— 后端必须加防护；
2. 忽略幂等性设计：防抖是 “阻止调用”，防重是 “保证结果一致”，比如支付接口，即使防抖失效，重复调用也不能扣两次钱；
3. Redis 过期时间设置不合理：太短导致正常请求被误判，太长导致用户无法重试 —— 建议根据业务调整，一般 1-5 秒。

四、选型指南：一张表选对方案

方案	适用场景	优点	缺点
Redis+Lua	分布式、高并发	性能高、支持分布式	需部署 Redis
Token 令牌	敏感接口（支付 / 退款）	最安全、防恶意刷接口	前后端联动成本高
本地缓存（Caffeine）	单机部署、高并发	响应快、无网络开销	不支持分布式
数据库唯一索引	核心业务兜底	最可靠、物理防护	影响插入性能
AOP + 自定义注解	大型项目、多场景	复用性强、优雅简洁	需提前封装

一句话口诀：分布式用 Redis，敏感接口用 Token，单机用 Caffeine，核心业务加索引。

五、总结

八年开发经验告诉我：接口防抖不是 “炫技”，而是 “底线思维”。一套完善的防抖方案，应该是 “前端按钮禁用 + 后端多重防护 + 数据库兜底” 的组合拳 —— 前端防普通用户，后端防恶意攻击，数据库防所有漏网之鱼。

本文的 5 种方案，从单机到分布式，从临时防护到长期复用，覆盖了所有场景，代码都经过实际项目验证，可直接复制使用。如果你的项目还在被重复提交困扰，不妨根据业务场景选择合适的方案，早日实现 “接口防抖自由”。