保障购物流程幂等性需服务端多层防护：①订单号服务端生成并设数据库唯一索引；②接口层用Redis幂等Token防重复提交；③复杂流程引入防重表与状态机；④分布式锁仅作临时兜底。
在Java项目中防止重复下单，核心是保障购物流程的幂等性——即同一笔业务请求无论调用多少次，结果都与调用一次一致。这不是靠前端拦截就能解决的，必须在服务端做多层防护。
订单号全局唯一 + 数据库唯一索引
这是最基础也最关键的防线。用户发起下单请求时，应由服务端生成全局唯一的订单号（如雪花ID、UUID+时间戳组合），并作为数据库订单表的主键或添加唯一索引字段（如 order_no）。
- 插入订单前不查重，直接执行 INSERT INTO order (...) VALUES (...) ON DUPLICATE KEY UPDATE ...（MySQL）或使用 INSERT ... SELECT ... WHERE NOT EXISTS 避免并发插入重复
- 若唯一约束触发异常（如 DuplicateKeyException），捕获后返回“订单已存在”，而不是抛错或重试
- 注意：不能依赖前端传来的订单号，必须服务端生成并控制
接口层增加幂等Token机制
适用于用户频繁点击“提交订单”按钮的场景。流程为：前端先调用 /api/token 获取一个短期有效的幂等Token，携带该Token发起下单请求，服务端校验并消耗Token。
- Token可存入Redis，设置5–10分钟过期，value记录关联的用户ID、订单业务类型、时间戳等
- 下单接口收到Token后，先用 SETNX + EXPIRE 原子操作尝试标记“已使用”，成功才继续处理；失败则直接返回“重复提交”
- Token建议一次性使用，避免被重放；也可支持有限次数（如最多2次），但需额外计数逻辑
业务状态机 + 防重查表（适用复杂流程）
当订单涉及库存预占、优惠券核销、支付回调等多个异步环节时，仅靠唯一索引不够。需引入轻量级防重表（order_idempotent）或状态字段控制流转。
Java 接口排错助手
下载
在调试 Java 后端 API 故障时使用此技能，尤其适用于以下任务：分析日志、跨 Controller、Service 和 Mapper 层追踪请求、定位异常根因、检查 SQL 执行或参数流转，以及生成简洁的诊断结论与修复方案。
立即学习“Java免费学习笔记（深入）”；
- 创建防重表：含 biz_type（如 “create_order”）、biz_key（如用户ID+商品ID+时间窗口哈希）、status（processing / success / failed）
- 下单前先插入该记录，利用数据库唯一约束保证幂等；后续所有子操作（扣库存、发消息等）都基于此记录状态判断是否执行
- 配合定时任务清理超时（如30分钟未完成）的 processing 记录，避免死锁
分布式锁兜底（慎用，非首选）
在极少数无法改造表结构或Token机制失效的遗留场景下，可用Redis分布式锁临时加一层保护，但不应作为主要方案。
- 锁key建议为 idempotent:order:${userId}:${cartHash}，过期时间设为业务最大耗时+冗余（如8秒）
- 必须使用原子命令（SET key value NX PX 8000）获取锁，并在finally块中校验value后释放，防止误删
- 注意：锁粒度要合理，避免锁住整个用户下单入口；高并发下锁竞争反而降低吞吐
基本上就这些。幂等不是加一个注解或中间件就能搞定的事，得结合业务阶段选策略：简单下单用唯一索引+Token；链路长的加状态机；锁只是临时补丁。关键在于——每次请求都要有可识别、可验证、可收敛的业务标识。
