在分布式系统或接口设计中，有哪些常见的幂等性实现方案？请结合你实际参与过的项目，说明具体采用了哪种方法以及落地细节。

回答思路

1. 【回答框架 1】幂等性指同一操作执行多次与执行一次结果一致，核心是防止重复请求造成数据不一致。常见实现方案包括：唯一索引或唯一约束、数据库乐观锁（版本号）、状态机流转、分布式锁、Token机制（预生成唯一令牌）、去重表（记录请求唯一标识）等。
2. 【回答框架 2】唯一索引或唯一约束适用于创建类操作，如订单号、支付流水号加唯一索引，重复插入直接报错或忽略；乐观锁适用于更新类操作，通过版本号或条件更新（如update where status=0）保证并发下只成功一次。
3. 【回答框架 3】状态机适用于订单、审批等有明确状态流转的场景，通过限制状态迁移方向（如已支付不能再次支付）实现幂等；Token机制适用于前端防重复提交，后端校验Token是否已消费；去重表则记录请求ID，处理前查询是否已存在。
4. 【回答框架 4】分布式锁（如Redis锁）只能保证互斥，不能直接保证业务幂等，还需配合唯一标识、状态记录或唯一约束才能实现完整幂等。实际项目中常组合使用，例如先获取Token，再通过唯一索引兜底。
5. 【回答框架 5】在我负责的支付回调项目中，采用‘请求唯一ID+去重表’方案：每次回调携带唯一ID，先查询去重表，存在则直接返回成功，不存在则插入并处理业务，同时用数据库唯一索引防止并发插入。
6. 【关键点 1】幂等核心是唯一标识加存储层约束，如唯一索引或去重表。
7. 【关键点 2】乐观锁通过版本号或条件更新保证更新操作幂等。
8. 【关键点 3】状态机限制状态流转方向，适用于订单等场景。
9. 【关键点 4】分布式锁只解决互斥，不直接保证幂等，需配合其他机制。
10. 【关键点 5】实际方案常组合使用，如Token加唯一索引兜底。
11. 【易错点 1】将分布式锁等同于幂等，忽略业务状态记录和唯一约束。
12. 【易错点 2】使用Redis锁时未考虑锁过期和重入问题，导致并发下重复处理。
13. 【易错点 3】去重表未加唯一索引，仅靠查询判断，并发下仍可能重复插入。