如何用防抖逻辑避免用户连击提交按钮导致的重复订单-js教程-PHP中文网

单纯靠前端防抖不能防止重复订单，必须前后端配合：前端立即禁用按钮并显示loading状态，后端用Redis setIfAbsent基于业务上下文（如用户ID+商品ID）加唯一令牌锁，过期时间略大于接口平均耗时，且key需通过SpEL动态生成，避免硬编码导致锁失效。

如何用防抖逻辑避免用户连击提交按钮导致的重复订单

单纯靠前端防抖不能防止重复订单，必须前后端配合——前端限制用户操作节奏，后端用唯一令牌校验请求合法性。

用户点击瞬间就要锁住按钮，不是等接口返回才处理。否则网络卡顿时，用户会反复点击，产生多个并发请求。

用 disabled 属性禁用按钮，同时配合 loading 状态显示（如 Element UI 的 :loading 或 Ant Design 的 loading 属性）
不要只依赖 setTimeout 恢复按钮，得在请求完成（无论 success 还是 error）后手动重置状态
Vue 场景下避免直接操作 DOM，优先用响应式数据控制 disabled 和文字，比如 :disabled="submitting"
React 场景下注意函数组件中闭包陷阱：submitting 状态更新后，事件回调里可能仍读到旧值，建议用 useRef 存储最新状态或用 useCallback 重新绑定

setIfAbsent 是原子操作，能真正防止并发写入。光靠数据库唯一索引或事务隔离级别扛不住高并发下的“时间差”问题。

key 要包含业务上下文，比如 "order:submit:uid_123:ts_1744800300"，不能只用用户 ID 或固定字符串
过期时间（lockTime）建议设为略大于接口平均耗时（如 5–8 秒），太短容易误放行，太长影响用户体验
别在 finally 里主动删 key——万一服务挂了，key 过期自动清理更安全；主动删反而可能删掉别人刚抢到的锁
异常抛出要用业务异常（如自定义 DuplicateSubmitException），别直接 throw new RuntimeException，否则全局异常处理器可能吞掉关键信息

注解里的 key 参数支持 SpEL，这是动态构造防重 key 的关键，写死就失去灵活性。

常见写法：@PreventDuplicateSubmit(key = "#request.getHeader('X-Request-ID')")，前提是前端带了该 header
更稳妥的是结合参数：@PreventDuplicateSubmit(key = "#order.userId + ':' + #order.productId")，但要注意空值导致 key 重复
如果参数是对象，SpEL 里取不到 getter 方法返回值（如 #order.getOrderId() 不生效），得确保字段是 public 或用 toString() 等可访问方式
Spring EL 解析失败时，buildLockKey 方法会拿到空字符串，最终 key 变成类似 "duplicate:submit:"，所有请求都撞同一个锁——这是线上最隐蔽的坑之一

真正难的不是写对一行 setIfAbsent，而是让前后端的“防抖窗口”对齐：前端禁用时长、后端锁过期时间、网关超时、客户端重试机制，四者稍有错位，就会漏防或误拦。上线前务必用 JMeter 或 wrk 模拟连击，观察日志里是否真只进一次切面、数据库是否只插入一条记录。