接口幂等性指同一操作多次请求对系统影响相同，java中常见实现方式包括：1. 唯一标识+redis缓存，通过requestid判断请求是否已处理；2. 数据库唯一约束+乐观锁，防止重复插入与并发更新；3. token机制，防前端重复提交；4. 状态机控制，基于业务状态流转限制操作。应根据场景选择方案，核心是在设计阶段识别需幂等的操作并提前防控。
接口幂等性是指同一个操作发起一次或多次请求，对系统产生的影响是相同的。在Java开发中，尤其在支付、订单创建、数据提交等场景下，防止重复请求造成数据重复处理非常关键。以下是几种常见的实现思路和具体做法。
1. 唯一标识 + 缓存机制（如Redis）
通过客户端传递一个唯一标识（如requestId、业务流水号），服务端利用缓存判断该请求是否已处理。
- 客户端每次请求时生成全局唯一ID（如UUID），并随请求发送
- 服务端接收到请求后，先检查Redis中是否存在该ID
- 若存在，说明请求已处理，直接返回之前结果
- 若不存在，执行业务逻辑，并将该ID写入Redis（可设置过期时间）
示例代码：
String requestId = request.getRequestId();
Boolean exists = redisTemplate.hasKey("request_id:" + requestId);
if (exists) {
return Response.alreadyProcessed();
}
// 执行业务
businessService.handle(request);
// 存储标记，设置30分钟过期
redisTemplate.opsForValue().set("request_id:" + requestId, "1", 30, TimeUnit.MINUTES);
2. 数据库唯一约束 + 乐观锁
利用数据库的唯一索引防止重复插入，结合版本号控制更新操作的幂等性。
立即学习“Java免费学习笔记（深入）”；
- 在订单表中添加唯一键（如外部订单号、用户+商品组合）
- 插入时若违反唯一约束，捕获异常并返回“已存在”提示
- 更新操作使用version字段，每次更新检查版本号是否匹配
例如：用户领取优惠券，限制每人限领一张，可用用户ID+优惠券ID建唯一索引。
3. Token机制（防重令牌）
适用于前端提交表单类操作，避免用户重复点击导致多次提交。
- 服务端生成Token并存储到Redis，返回给前端
- 前端携带Token请求接口
- 服务端校验Token是否存在，存在则删除并继续处理，否则拒绝请求
这种机制常用于下单、提现等敏感操作，确保一次有效提交。
4. 状态机控制
对于有明确状态流转的业务（如订单状态：待支付→已支付→已完成），通过判断当前状态决定是否允许操作。
- 每次操作前检查资源当前状态
- 只有在指定状态下才允许执行对应动作
- 例如：已支付的订单不能再触发支付流程
这种方式天然具备幂等性，适合复杂业务流程。
基本上就这些。选择哪种方式取决于具体业务场景。简单操作可用Redis去重，涉及数据一致性建议结合数据库约束，高并发场景推荐Token+缓存组合方案。关键是识别哪些操作需要幂等，并在设计阶段就考虑防护措施。
