幂等实现方案（详解+方案对比）

在分布式系统、接口调用、数据同步等场景中，因网络波动、重试机制、服务宕机、消息重复投递等问题，常会出现“重复请求/重复处理”的情况，进而导致数据不一致（如重复下单、重复扣款、重复入库）。幂等性的核心目标是：同一请求（或同一操作）无论执行多少次，最终结果都一致，不会产生副作用。

幂等实现的核心思路的是“识别重复请求/操作”并“拒绝重复处理”，不同方案的差异主要集中在“识别精度、性能开销、适用场景、实现复杂度”四个维度。本文将详解6种主流幂等实现方案，覆盖接口层、业务层、数据层，结合Java实战场景拆解，再通过多维度对比，帮助开发者快速选型。

核心前提：幂等实现需结合业务场景选择，没有通用最优方案，优先保证“识别准确”和“性能可控”，避免过度设计；同时需区分“天然幂等”和“人工实现幂等”——天然幂等操作（如查询、删除不存在的数据）无需额外处理，非天然幂等操作（如下单、扣款）需手动实现幂等。

一、6种主流幂等实现方案详解（实战视角）

以下方案按“实现成本从低到高、适用范围从广到专”排序，覆盖接口调用、消息消费、数据操作等常见场景，均结合Java实战代码示例，便于落地。

方案1：基于唯一标识（Token/请求ID）实现幂等（最常用、通用性强）

1. 核心原理

核心逻辑：客户端发起请求前，先向服务端申请一个全局唯一标识（Token/请求ID），客户端携带该标识发起请求；服务端接收请求后，先校验该标识是否已被处理，若未处理则执行业务逻辑，处理完成后标记该标识为“已处理”；若已处理则直接返回成功（或处理结果），拒绝重复执行。

核心关键：唯一标识需全局唯一（如UUID、雪花ID），且需通过“持久化存储”（如Redis、数据库）记录标识的处理状态，确保服务宕机后仍能识别重复请求。

2. 实战实现（Java+Redis）

// 1. 生成全局唯一Token（客户端申请Token接口）
@GetMapping("/get-idempotent-token")
public String getIdempotentToken() {// 生成全局唯一Token（UUID/Snowflake ID）String token = UUID.randomUUID().toString().replace("-", "");// 存储到Redis，设置过期时间（根据业务场景设置，如30分钟）redisTemplate.opsForValue().set("idempotent:token:" + token, "UNPROCESSED", 30, TimeUnit.MINUTES);return token;
}// 2. 接口幂等校验（核心业务接口）
@PostMapping("/submit-order")
public Result submitOrder(@RequestHeader("Idempotent-Token") String token, @RequestBody OrderDTO orderDTO) {// 1. 校验Token是否存在且未处理String key = "idempotent:token:" + token;String status = redisTemplate.opsForValue().get(key);if (status == null) {return Result.fail("请求无效或已过期");}if ("PROCESSED".equals(status)) {return Result.success("请求已处理，无需重复提交");}// 2. 原子性校验+标记（避免并发重复处理，Redis SETNX）Boolean isSuccess = redisTemplate.opsForValue().setIfAbsent(key, "PROCESSED", 30, TimeUnit.MINUTES);if (!isSuccess) {return Result.success("请求已处理，无需重复提交");}// 3. 执行核心业务逻辑（如下单）try {orderService.createOrder(orderDTO);return Result.success("下单成功");} catch (Exception e) {// 业务失败，回滚Token状态（可选，根据业务场景）redisTemplate.opsForValue().set(key, "UNPROCESSED", 30, TimeUnit.MINUTES);return Result.fail("下单失败，请重试");}
}

3. 优点

通用性极强：适配所有非天然幂等场景（如下单、扣款、接口调用），无业务侵入性。
实现灵活：可结合Redis、数据库等多种存储，支持分布式场景。
识别精准：基于全局唯一标识，可精准识别重复请求，避免误判。
性能可控：Redis存储时，操作均为原子性，性能损耗低，支持高并发。

4. 缺点

增加接口调用次数：客户端需先申请Token，再发起业务请求，多一次接口交互。
需处理Token过期：过期时间设置过短，可能导致正常请求失效；设置过长，占用存储资源。
依赖外部存储：需依赖Redis、数据库等，增加系统复杂度，需考虑存储服务的可用性。

5. 使用场景

适用于「所有非天然幂等的接口场景」，尤其是分布式系统、高并发场景，如：

电商下单、支付接口（避免重复下单、重复扣款）；
第三方接口调用（避免重复回调、重复处理）；
表单提交（避免用户重复点击导致重复提交）。

方案2：基于数据库唯一索引实现幂等（数据层保障，最可靠）

1. 核心原理

核心逻辑：利用数据库的唯一索引（主键/唯一约束）特性，将“唯一标识业务操作”的字段设为唯一索引；当重复请求触发业务逻辑，执行数据库插入操作时，因唯一索引冲突，数据库会抛出主键冲突/唯一约束异常，服务端捕获异常后，判定为重复请求，直接返回成功（或处理结果），不执行后续业务逻辑。

核心关键：唯一索引的字段需能精准标识“同一业务操作”（如订单号、支付流水号、用户ID+业务类型），避免误判。

2. 实战实现（MySQL+Java）

// 1. 数据库表设计（以订单表为例，订单号设为唯一索引）
CREATE TABLE `t_order` (`id` bigint NOT NULL AUTO_INCREMENT COMMENT '订单ID',`order_no` varchar(64) NOT NULL COMMENT '订单号（唯一）',`user_id` bigint NOT NULL COMMENT '用户ID',`amount` decimal(10,2) NOT NULL COMMENT '订单金额',`status` tinyint NOT NULL COMMENT '订单状态',PRIMARY KEY (`id`),UNIQUE KEY `uk_order_no` (`order_no`) -- 唯一索引，保障幂等
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='订单表';// 2. Java业务实现（捕获唯一约束异常）
@Service
public class OrderServiceImpl implements OrderService {@Autowiredprivate OrderMapper orderMapper;@Override@Transactionalpublic void createOrder(OrderDTO orderDTO) {try {// 1. 构建订单对象（订单号全局唯一，如雪花ID生成）Order order = new Order();order.setOrderNo(SnowflakeIdUtil.nextIdStr());order.setUserId(orderDTO.getUserId());order.setAmount(orderDTO.getAmount());order.setStatus(1); // 待支付// 2. 插入数据库（若订单号重复，会抛出唯一约束异常）orderMapper.insert(order);// 3. 执行后续业务（如扣减库存）stockService.deductStock(orderDTO.getProductId(), orderDTO.getQuantity());} catch (DuplicateKeyException e) {// 捕获唯一约束异常，判定为重复下单，不做任何处理（或返回已存在的订单）log.warn("重复下单，订单号：{}", orderDTO.getOrderNo());// 可选：查询已存在的订单，返回给客户端Order existOrder = orderMapper.selectByOrderNo(orderDTO.getOrderNo());if (existOrder != null) {throw new BusinessException("订单已存在，无需重复提交", existOrder);}}}
}

3. 优点

可靠性高：基于数据库唯一约束，从数据层直接保障幂等，无漏判、误判风险。
无额外依赖：无需依赖Redis等外部存储，仅依赖数据库，降低系统复杂度。
实现简单：只需设计合理的唯一索引，捕获异常即可，开发成本低。
适配分布式：支持分布式场景，只要数据库集群一致，即可实现跨节点幂等。

4. 缺点

业务侵入性强：需结合业务表设计唯一索引，若业务字段变更，需修改表结构。
性能损耗：高并发场景下，大量重复请求会触发数据库异常，增加数据库压力。
仅适用于插入场景：主要用于“插入数据”的幂等，对更新、删除场景适配性差。

5. 使用场景

适用于「数据插入类场景」，尤其是对数据一致性要求高、不希望依赖外部存储的场景，如：

订单创建、支付流水记录（订单号、流水号唯一）；
用户积分记录、账单记录（用户ID+业务类型+时间戳唯一）；
数据同步场景（如从第三方同步数据，避免重复入库）。

方案3：基于数据库乐观锁实现幂等（更新场景首选）

1. 核心原理

核心逻辑：针对“更新操作”，在数据库表中增加一个版本号（version）或时间戳（update_time）字段；每次更新数据时，带上当前版本号，数据库执行更新语句时，校验版本号是否匹配（如version = 传入版本号）；若匹配则更新数据，并递增版本号；若不匹配（说明数据已被其他请求更新，即重复请求），则拒绝更新，返回成功或失败。

核心关键：版本号需随每次更新递增，确保每次更新操作的版本唯一，避免重复更新。

2. 实战实现（MySQL+Java）

// 1. 数据库表设计（以库存表为例，增加version字段）
CREATE TABLE `t_stock` (`id` bigint NOT NULL AUTO_INCREMENT COMMENT '库存ID',`product_id` bigint NOT NULL COMMENT '商品ID',`stock_num` int NOT NULL COMMENT '库存数量',`version` int NOT NULL DEFAULT 0 COMMENT '版本号（乐观锁）',PRIMARY KEY (`id`),UNIQUE KEY `uk_product_id` (`product_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='库存表';// 2. Java业务实现（乐观锁更新）
@Service
public class StockServiceImpl implements StockService {@Autowiredprivate StockMapper stockMapper;@Override@Transactionalpublic boolean deductStock(Long productId, int quantity) {// 1. 查询当前库存及版本号Stock stock = stockMapper.selectByProductId(productId);if (stock == null || stock.getStockNum() < quantity) {return false; // 库存不足}// 2. 乐观锁更新（版本号匹配才更新）int rows = stockMapper.deductStock(productId, quantity, stock.getVersion() // 传入当前版本号);// 3. 判断更新结果：rows=0表示版本不匹配（重复请求/并发更新）if (rows == 0) {log.warn("库存扣减失败，可能是重复请求或并发更新，商品ID：{}", productId);return true; // 幂等处理，返回成功（避免重复重试）}return true;}
}// 3. Mapper接口（XML）
<update id="deductStock">UPDATE t_stock SET stock_num = stock_num - #{quantity}, version = version + 1WHERE product_id = #{productId} AND version = #{version}
</update>

3. 优点

适配更新场景：专门用于“数据更新”的幂等，解决重复更新导致的数据不一致问题。
性能较好：无锁机制，通过版本号校验实现并发控制，性能优于悲观锁。
实现简单：只需增加版本号字段，修改更新语句，开发成本低。
无额外依赖：仅依赖数据库，无需外部存储，运维成本低。

4. 缺点

仅适用于更新场景：对插入、删除场景适配性差，无法单独实现全场景幂等。
并发冲突处理：高并发场景下，版本号不匹配会导致更新失败，需配合重试机制。
业务侵入性：需修改表结构，增加版本号字段，对现有业务有一定影响。

5. 使用场景

适用于「数据更新类场景」，尤其是高并发更新、需要避免重复更新的场景，如：

库存扣减、余额更新（避免重复扣减、重复加钱）；
订单状态更新（如待支付→已支付，避免重复更新状态）；
商品信息更新（避免并发更新导致的数据错乱）。

方案4：基于状态机实现幂等（状态流转场景）

1. 核心原理

核心逻辑：针对“有状态流转的业务”（如订单、支付），通过状态机约束实现幂等——每个业务操作对应一个状态，且状态流转有固定顺序（如订单：待支付→已支付→已发货→已完成）；当重复请求触发业务操作时，若当前状态不满足操作要求（如已支付的订单再次触发支付），则拒绝执行，直接返回当前状态结果。

核心关键：状态流转需有明确的规则，且状态字段需持久化，确保服务宕机后状态不丢失。

2. 实战实现（订单状态机为例）

// 1. 订单状态枚举（定义状态流转规则）
public enum OrderStatusEnum {WAIT_PAY(1, "待支付"),PAID(2, "已支付"),SHIPPED(3, "已发货"),COMPLETED(4, "已完成"),CANCELLED(5, "已取消");// 状态流转校验：判断当前状态是否能执行目标操作public boolean canPay() {return this == WAIT_PAY; // 只有待支付状态能执行支付操作}public boolean canCancel() {return this == WAIT_PAY; // 只有待支付状态能取消订单}// 省略getter、构造方法
}// 2. Java业务实现（状态机幂等校验）
@Service
public class OrderServiceImpl implements OrderService {@Autowiredprivate OrderMapper orderMapper;@Override@Transactionalpublic void payOrder(Long orderId, String payNo) {// 1. 查询订单当前状态Order order = orderMapper.selectById(orderId);if (order == null) {throw new BusinessException("订单不存在");}// 2. 状态机校验：判断当前状态是否能执行支付操作（幂等核心）if (!OrderStatusEnum.getById(order.getStatus()).canPay()) {log.warn("订单无法支付，当前状态：{}，订单ID：{}", order.getStatus(), orderId);return; // 重复支付请求，直接返回}// 3. 执行支付业务逻辑（如调用支付接口）payService.pay(payNo, order.getAmount());// 4. 更新订单状态order.setStatus(OrderStatusEnum.PAID.getCode());order.setPayNo(payNo);orderMapper.updateById(order);}
}

3. 优点

贴合业务场景：与有状态流转的业务高度契合，幂等校验自然融入业务逻辑。
无额外开销：无需依赖外部存储、无需修改表结构（仅需状态字段），性能损耗低。
逻辑清晰：状态流转规则明确，便于维护和扩展，可避免非法状态变更。

4. 缺点

适用场景有限：仅适用于“有状态流转”的业务，无状态业务（如查询、简单插入）无法使用。
状态规则复杂：若业务状态流转复杂（多状态、多分支），状态校验逻辑会变得繁琐。
需配合其他方案：无法单独应对所有重复场景（如订单未创建时的重复下单），需配合Token或唯一索引。

5. 使用场景

适用于「有状态流转的业务场景」，尤其是状态变更有明确规则的场景，如：

订单业务（待支付→已支付→已发货→已完成）；
支付业务（待支付→支付中→支付成功→支付失败）；
工单业务（待处理→处理中→已完成→已关闭）。

方案5：基于消息幂等表实现幂等（消息消费场景）

1. 核心原理

核心逻辑：针对“消息队列重复投递”场景（如RabbitMQ、Kafka消息重复消费），创建一张消息幂等表，用于记录已消费的消息ID；消费者接收消息后，先查询幂等表，若消息ID已存在（已消费），则直接丢弃消息；若不存在，则执行消费逻辑，消费完成后将消息ID插入幂等表（通过唯一索引保障不重复插入）。

核心关键：消息ID需全局唯一（如消息队列的messageId、业务自定义唯一ID），幂等表需设计唯一索引，确保消息不重复消费。

2. 实战实现（RabbitMQ+MySQL）

// 1. 消息幂等表设计
CREATE TABLE `t_message_idempotent` (`id` bigint NOT NULL AUTO_INCREMENT COMMENT 'ID',`message_id` varchar(64) NOT NULL COMMENT '消息唯一ID',`business_type` varchar(32) NOT NULL COMMENT '业务类型（如订单、支付）',`consumer_time` datetime NOT NULL COMMENT '消费时间',PRIMARY KEY (`id`),UNIQUE KEY `uk_message_id` (`message_id`) -- 唯一索引，避免重复消费
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='消息幂等表';// 2. RabbitMQ消费者实现（幂等校验）
@Component
public class OrderMessageConsumer {@Autowiredprivate RabbitTemplate rabbitTemplate;@Autowiredprivate MessageIdempotentMapper idempotentMapper;@Autowiredprivate OrderService orderService;@RabbitListener(queues = "order.queue")public void consume(Message message, Channel channel) throws IOException {String messageId = message.getMessageProperties().getMessageId();try {// 1. 幂等校验：查询消息是否已消费MessageIdempotent exist = idempotentMapper.selectByMessageId(messageId);if (exist != null) {log.warn("消息已消费，无需重复处理，消息ID：{}", messageId);channel.basicAck(message.getMessageProperties().getDeliveryTag(), false);return;}// 2. 解析消息，执行消费逻辑（如下单）String body = new String(message.getBody(), StandardCharsets.UTF_8);OrderDTO orderDTO = JSON.parseObject(body, OrderDTO.class);orderService.createOrder(orderDTO);// 3. 消费成功，插入幂等表MessageIdempotent idempotent = new MessageIdempotent();idempotent.setMessageId(messageId);idempotent.setBusinessType("ORDER_CREATE");idempotent.setConsumerTime(new Date());idempotentMapper.insert(idempotent);// 4. 确认消息消费成功channel.basicAck(message.getMessageProperties().getDeliveryTag(), false);} catch (Exception e) {// 消费失败，拒绝消息，避免重复投递（根据业务场景调整）channel.basicNack(message.getMessageProperties().getDeliveryTag(), false, false);log.error("消息消费失败，消息ID：{}", messageId, e);}}
}

3. 优点

专门适配消息消费：精准解决消息队列重复投递、重复消费的问题，贴合消息驱动架构。
可靠性高：基于数据库唯一索引，确保消息不重复消费，数据一致性有保障。
可追溯：幂等表记录消息消费时间、业务类型，便于排查问题、追溯消费记录。

4. 缺点

场景单一：仅适用于消息消费场景，无法用于普通接口幂等。
增加数据库压力：每次消费消息都需查询、插入幂等表，高并发消息场景下会增加数据库负担。
需配合消息确认：需与消息队列的ACK机制配合，避免消息丢失或重复消费。

5. 使用场景

适用于「消息驱动架构、消息队列重复消费」的场景，如：

RabbitMQ、Kafka消息消费（如订单创建、库存扣减的消息消费）；
分布式事务中的消息补偿场景（避免补偿消息重复执行）；
第三方消息回调（如支付回调消息，避免重复回调消费）。

方案6：基于分布式锁实现幂等（高并发场景）

1. 核心原理

核心逻辑：针对高并发场景，通过分布式锁（如Redisson、ZooKeeper）锁定“唯一业务标识”（如订单号、用户ID+业务类型）；当请求到达时，先尝试获取分布式锁，获取成功则执行业务逻辑，执行完成后释放锁；若获取失败（说明有其他请求正在执行），则判定为重复请求，直接返回成功或等待重试。

核心关键：锁的key需能精准标识“同一业务操作”，且锁需设置过期时间，避免死锁；同时需确保锁的原子性，避免并发问题。

2. 实战实现（Redisson分布式锁）

@Service
public class OrderServiceImpl implements OrderService {@Autowiredprivate RedissonClient redissonClient;@Autowiredprivate OrderMapper orderMapper;@Overridepublic Result createOrder(OrderDTO orderDTO) {// 1. 定义分布式锁的key（唯一标识业务操作：用户ID+订单号）String lockKey = "idempotent:order:" + orderDTO.getUserId() + ":" + orderDTO.getOrderNo();RLock lock = redissonClient.getLock(lockKey);try {// 2. 尝试获取锁（超时时间3秒，自动释放时间10秒）boolean isLocked = lock.tryLock(3, 10, TimeUnit.SECONDS);if (!isLocked) {// 获取锁失败，判定为重复请求return Result.success("请求正在处理中，无需重复提交");}// 3. 执行核心业务逻辑（如下单）Order order = new Order();order.setOrderNo(orderDTO.getOrderNo());order.setUserId(orderDTO.getUserId());order.setAmount(orderDTO.getAmount());orderMapper.insert(order);return Result.success("下单成功");} catch (InterruptedException e) {log.error("下单失败，用户ID：{}，订单号：{}", orderDTO.getUserId(), orderDTO.getOrderNo(), e);return Result.fail("下单失败，请重试");} finally {// 4. 释放锁（确保当前线程持有锁再释放）if (lock.isHeldByCurrentThread()) {lock.unlock();}}}
}

3. 优点

适配高并发：分布式锁性能优秀，支持高并发场景，可有效防止并发重复请求。
灵活性高：可适配插入、更新、删除等多种业务场景，无严格业务限制。
无数据侵入：无需修改数据库表结构，仅通过锁机制实现幂等，业务侵入性低。

4. 缺点

依赖外部组件：需依赖Redisson、ZooKeeper等分布式锁组件，增加系统复杂度。
锁超时风险：锁过期时间设置不当，可能导致锁提前释放，引发重复处理；设置过长，可能导致死锁。
性能损耗：高并发场景下，锁竞争会带来一定的性能损耗，需优化锁粒度。

5. 使用场景

适用于「高并发场景、多种业务类型」，尤其是需要避免并发重复处理的场景，如：

高并发下单、支付接口（避免并发重复下单）；
分布式系统中的数据同步（避免并发同步导致的数据不一致）；
高频接口的幂等控制（如秒杀接口，避免重复抢购）。

二、6种幂等方案多维度对比（选型核心参考）

从「适用场景、实现成本、性能开销、可靠性、业务侵入性、依赖组件」6个核心维度，对6种方案进行对比，明确选型优先级，贴合实战落地需求：

对比维度	唯一标识（Token）	数据库唯一索引	数据库乐观锁	状态机	消息幂等表	分布式锁
适用场景	所有非天然幂等场景（接口、下单等）	数据插入场景	数据更新场景	有状态流转的业务	消息消费场景	高并发、多业务场景
实现成本	中（需生成Token+存储校验）	低（仅需建索引+捕获异常）	低（需加版本号+修改SQL）	中（需设计状态规则）	中（需建幂等表+消息校验）	高（需部署分布式锁组件）
性能开销	低（Redis原子操作）	中（数据库异常捕获）	低（无锁更新）	极低（仅状态判断）	中（数据库查询+插入）	中（锁竞争损耗）
可靠性	高（唯一标识+持久化）	极高（数据库约束）	高（版本号校验）	中（依赖状态规则）	极高（数据库约束）	中（依赖锁组件可用性）
业务侵入性	低（无业务逻辑侵入）	高（需修改表结构）	高（需修改表结构+SQL）	中（需融入业务状态）	中（需新增幂等表）	低（仅加锁校验）
依赖组件	Redis/数据库	无（仅数据库）	无（仅数据库）	无	无（仅数据库）	Redisson/ZK等
推荐度（通用场景）	★★★★★（首选）	★★★★☆（插入场景首选）	★★★★☆（更新场景首选）	★★★☆☆（状态流转场景）	★★★★☆（消息消费首选）	★★★☆☆（高并发场景）

三、选型指南（实战落地建议）

选型核心原则：优先根据“业务场景、并发量、数据一致性要求”选型，兼顾实现成本和运维成本，避免过度设计；实际落地中，常采用“多种方案组合”的方式，覆盖全场景幂等。

1. 通用场景（无特殊限制）→ 唯一标识（Token）方案

若业务场景无特殊限制（如既有插入、又有更新），优先选择Token方案，通用性强、实现灵活，可结合Redis实现高并发支持，适配大多数接口幂等需求，是目前最主流的幂等实现方案。

2. 插入场景（如订单创建、流水记录）→ 数据库唯一索引方案

若仅需实现“插入数据”的幂等，且对数据一致性要求高，优先选择数据库唯一索引方案，可靠性高、无额外依赖，开发成本低，无需担心重复插入问题。

3. 更新场景（如库存扣减、状态更新）→ 数据库乐观锁方案

若需实现“更新数据”的幂等，避免重复更新导致的数据不一致，优先选择乐观锁方案，性能好、实现简单，适配高并发更新场景，是更新场景的首选。

4. 状态流转场景（如订单、支付）→ 状态机+唯一索引/Token

若业务有明确的状态流转规则，采用“状态机+唯一索引/Token”的组合方案：状态机用于校验状态合法性，避免非法状态变更；唯一索引/Token用于防止重复请求（如重复下单），兼顾业务合理性和幂等性。

5. 消息消费场景（如RabbitMQ/Kafka）→ 消息幂等表方案

若为消息驱动架构，需解决消息重复消费问题，优先选择消息幂等表方案，结合数据库唯一索引，确保消息不重复消费，同时可追溯消费记录，便于排查问题。

6. 高并发场景（如秒杀、高频下单）→ 分布式锁+Token方案

若业务并发量极高，需避免并发重复处理，采用“分布式锁+Token”的组合方案：分布式锁用于控制并发请求，Token用于精准识别重复请求，兼顾高并发和幂等性，确保系统稳定。

四、关键注意事项（必看）

唯一标识的设计：无论哪种方案，“唯一标识”的设计是核心，需确保能精准标识“同一业务操作”（如用户ID+订单号、消息ID），避免误判（如不同用户的相同订单号不应判定为重复）。
持久化存储：依赖存储的方案（Token、唯一索引、幂等表），需确保存储服务的高可用（如Redis集群、数据库主从），避免存储服务宕机导致幂等失效。
过期时间设置：Token、分布式锁等方案，需合理设置过期时间，既要避免过期时间过短导致正常请求失效，也要避免过期时间过长占用资源或导致死锁。
异常处理：需妥善处理业务异常、存储异常，如Token方案中业务失败需回滚Token状态，消息幂等表方案中消费失败需拒绝消息，避免幂等校验失效。
避免过度设计：简单场景（如低并发、非核心业务）无需使用复杂方案（如分布式锁），采用唯一索引、状态机即可，降低开发和运维成本。
结合业务逻辑：幂等实现需融入业务逻辑，避免脱离业务的“机械幂等”，如状态机方案需贴合业务状态流转规则，不能单纯为了幂等而设计。