Python接口幂等设计核心是重复请求结果一致、状态不变，手段包括唯一标识+状态校验、数据库唯一约束、Redis预占位、慎用分布式锁，并需结合业务语义设计状态机。
Python接口做幂等设计，核心是让同一请求重复执行时结果一致，不产生副作用。重点不是“防止重复提交”，而是“重复提交后系统状态不变”。常见手段包括唯一标识+状态校验、数据库唯一约束、缓存预占位、分布式锁（慎用）等。
用请求ID + 状态表保障业务幂等
客户端每次请求携带唯一id（如UUID），服务端在处理前先查该ID是否已成功处理过：
- 查到且状态为success → 直接返回原结果，不执行业务逻辑
- 查到但状态为processing → 可选择等待或返回“处理中”
- 未查到 → 插入新记录（status=processing），再执行业务；成功后更新为success
注意：插入需用数据库唯一索引（如联合索引 (request_id, biz_type)），避免并发插入重复记录。
利用数据库唯一约束自动拦截
对关键业务操作（如创建订单、发优惠券），在表中加唯一字段（如order_no、coupon_code），由客户端或服务端生成全局唯一值。
立即学习“Python免费学习笔记（深入）”；
- 插入前不查，直接INSERT，靠数据库唯一约束报错拦截重复
- 捕获
IntegrityError，判断是否为唯一键冲突，若是则查询已有记录并返回 - 比“先查后插”更可靠，避免查插之间的时间窗口问题
Redis预占位：轻量级快速判重
适合高频、低一致性要求的场景（如点赞、限频、秒杀预减库存）：
- 用
SET key value EX 60 NX命令设置带过期时间的唯一key（如req:12345） - 返回True表示首次请求，可继续执行；False说明已存在，直接返回成功响应
- 注意：Redis单点故障或网络分区时可能失效，不能替代数据库层幂等
避免滥用分布式锁
锁只是手段，不是幂等本身。为幂等加锁容易引入性能瓶颈和死锁风险：
- 仅在必须串行执行且无法用唯一约束/状态表解决时才考虑（如复杂多步资金流水）
- 优先选Redis Redlock或ZooKeeper临时有序节点，设置合理超时和自动续期
- 锁粒度尽量小（按业务主键，而非全局），且必须有finally释放逻辑
幂等不是加一层校验就完事，关键是结合业务语义设计状态机。比如支付回调，应区分“未支付”、“已支付”、“已退款”，而不是只记“是否处理过”。不复杂但容易忽略。
