结论：幂等指同一请求执行一次和执行多次的业务效果相同。在超时重试、消息重投、前端重复提交不可避免的前提下，写接口必须幂等，核心手段是唯一标识 + 去重判重。

展开：分层方案：1）天然幂等优先：查询、删除（删两次结果一致）、覆盖式更新（set status=X）天然幂等，能用就不用额外机制。2）唯一约束兜底：数据库唯一索引是最可靠防线，插入冲突即重复请求，如订单号唯一索引防重复下单。3）去重表/Token 机制：客户端先申请一次性 Token，提交时服务端校验 Token 存在性并原子删除（Redis SETNX 或 GETDEL），防表单重复提交。4）状态机约束：更新带前置状态条件（乐观锁 UPDATE ... SET status=2 WHERE id=? AND status=1），影响行数为 0 说明已处理过。5）消息消费端：以消息 ID 或业务键做去重表，配合本地事务（去重与业务写入同库同事务）保证 exactly-once 语义，这是 MQ 消费必考点。关键细节：判重和写库必须原子，否则并发下两请求都通过检查；分布式锁只作性能优化不作正确性保证，正确性永远靠唯一约束。追问方向：防重与幂等的区别——防重拦并发重复，幂等允许重试结果一致，通常两者一起设计。