接口幂等性指多次调用结果一致，常用实现方式包括：1. 唯一标识+Redis缓存，利用SETNX防止重复提交；2. 数据库唯一约束，通过唯一索引避免重复插入；3. 状态机控制，条件更新确保状态流转幂等；4. Token机制，防重令牌一次性使用。实际中可组合使用，如Redis与数据库约束结合，保障核心操作数据一致性。
接口幂等性是指无论调用一次还是多次，结果都保持一致。在Java后端开发中，尤其在支付、订单创建等场景下，保证接口幂等性非常关键。以下是几种常用且有效的实现方式。
1. 唯一标识 + Redis 缓存
客户端在发起请求时携带一个唯一标识（如UUID），服务端在处理前先检查该标识是否已存在。
实现步骤：
- 客户端生成requestId并传入请求头或参数中
- 服务端接收到请求后，使用Redis的red">SETNX命令尝试写入requestId，设置过期时间（如5分钟）
- 如果写入成功，继续执行业务逻辑；如果已存在，则直接返回之前的结果或提示重复提交
这种方式简单高效，适合大多数场景。
立即学习“Java免费学习笔记（深入）”；
2. 数据库唯一约束
利用数据库的唯一索引来防止重复操作。
例如在创建订单时，将用户ID、业务类型和外部订单号组合成唯一索引。
说明：
- 当插入重复记录时，数据库会抛出唯一键冲突异常
- 服务端捕获该异常后返回“操作已存在”，而不是报错
- 需配合事务使用，确保原子性
适用于创建类操作，比如订单、提现申请等。
3. 状态机控制
通过状态字段限制操作的可执行条件。
比如订单状态为“待支付”才能执行取消操作，一旦变为“已取消”或“已完成”，再次取消不生效。
建议：
- 在更新状态时使用条件更新，如UPDATE order SET status = 'CANCELLED' WHERE id = ? AND status = 'UNPAID'
- 根据影响行数判断是否执行成功，影响0行说明已处理过或状态不符
这种方案天然具备幂等特性，适合有明确状态流转的业务。
4. Token机制（防重令牌）
服务端提前下发一个token，客户端必须携带该token才能执行敏感操作。
流程如下：
- 用户进入页面时，后端生成token存入Redis，并返回给前端
- 提交请求时携带此token
- 服务端校验token是否存在，存在则删除并执行业务，否则拒绝请求
由于token被消费后即失效，无法重复提交，有效防止重复操作。
基本上就这些常用方法。实际项目中可以结合使用，比如“Redis去重 + 数据库约束”双保险。关键是根据业务场景选择合适方案，确保核心操作不会因重复请求导致数据错乱。
