好这个问题非常关键尤其是在金融、支付、电商、表单提交流水线等场景理解“为什么用幂等 防重复提交”和“它和其他方案比的优势”是做高可靠系统的核心。一、为什么要做幂等防重复提交1️⃣ 重复请求是现实世界里的必然在真实网络环境中以下情况非常常见用户手抖多点了一次提交按钮网络慢用户连续点击刷新移动端信号差导致请求重发网关 / 负载均衡 / MQ重试机制前端超时重试逻辑 如果不做幂等防护就会出现同一个订单被创建了两次同一笔钱扣了两次同一个优惠券被领了两次2️⃣ 幂等的意义幂等Idempotent多次执行同一个请求结果和业务状态是一致的。举例操作幂等期望提交订单第二次调用不会新建订单扣款第二次调用不会重复扣钱领取优惠券第二次调用不会多发一张幂等的目标是保护业务数据正确性而非单纯防 UI 误操作二、幂等防重复提交的底层逻辑核心思路用一个唯一的标识Request Key绑定一次有效的业务执行权流程客户端发起请求 → 带上唯一 Request Keytoken / 参数哈希 ↓ 服务端 Redis SET NX Key ↓ Key 不存在 → 允许执行 → 写入 RedisNX TTL Key 已存在 → 拒绝重复 → 返回错误或忽略 ↓ 业务执行完后可选择删除 Key也可 TTL 自动过期关键点唯一标识token / userIdbizId / 参数哈希原子操作RedisSET key value NX EX时效性Key 有过期时间避免死锁无状态不依赖会话天然支持分布式三、和其他防重方案的对比方案原理优点缺点适用场景Redis 幂等​SET NX 锁快、分布式、无侵入依赖 Redis 高可用高并发、跨服务、支付/下单数据库唯一索引唯一约束强一致、不依赖外部中间件侵入表结构难扩展多业务单表强唯一如订单号Session 防重存 token 在 session简单不支持分布式易丢失老式单体 Web 项目前端防重禁用按钮、Loading减轻压力不可靠可绕过辅助手段不能单独用请求去重表DB插入流水表判断可审计高并发下性能差低频场景如审批流消息队列去重消费组 MessageID解耦、天然去重只适用于 MQ 场景异步处理任务综合来看Redis 幂等是性能、通用性、分布式能力之间平衡最好的方案。四、为什么不用唯一索引代替唯一索引只能解决入库阶段冲突无法阻止业务逻辑多次执行比如库存扣减两次。幂等是在入口层就拦截减少无效计算和下游副作用。唯一索引维护成本高新增字段、迁移历史数据。唯一索引无法应对跨表、跨服务的幂等需求比如支付回调。五、Redis 幂等的优势总结✅高性能内存操作毫秒级响应✅分布式友好所有节点共享同一个 Redis天然跨 JVM / 跨服务✅灵活定制Key 可按业务动态拼token、参数哈希、用户业务ID✅时效可控TTL 自动过期不怕死锁✅无侵入注解AOP不改业务逻辑✅适配重试场景MQ / Feign / Gateway 重试不会导致重复执行六、什么场景必须用幂等绝对不能重复的业务支付扣款 / 退款下单 / 创建订单发放优惠券 / 积分短信验证码发送审批流提交库存扣减可以容忍重复但要防副作用的查询接口天生幂等导入数据幂等校验主键七、一句话总结可直接背幂等防重复提交是为了解决网络重发、用户误操作、系统重试导致的多次执行业务的问题它通过 Redis SET NX 原子锁在入口层拦截重复请求相比数据库唯一索引或 Session 等方式具有高性能、分布式支持好、无侵入和灵活性强的优势是高并发互联网业务的标配防护手段。如果你想我可以帮你画一个幂等与其他方案的全景对比图文字版或者写一个支付回调的幂等实战模板你要继续吗