go语言高并发幂等控制核心是redis setnx+ex原子拦截（key含业务上下文、value存idempotency_key或trace_id、ttl≥最长耗时+余量）、数据库唯一索引兜底、select for update行锁防状态竞态、异步任务用状态机+幂等键，redis故障须返回503而非放行。
Go语言在高并发下做幂等控制，核心是「一次判断、原子执行、分层兜底」。不能靠前端防重或HTTP方法语义糊弄，必须在服务入口就卡住重复请求，同时确保失败不误拦、成功不漏判。
用 Redis SetNX + EX 做首道原子拦截
这是最常用也最稳的第一道防线。关键不是“用了Redis”，而是命令必须原子、过期必须内建、key必须带业务上下文：
- 必须用
rdb.SetNX(ctx, key, value, ttl)（Go-Redis v9），它底层自动拼NX EX，避免拆成 EXISTS+SET 或 SETNX+EXPIRE 的竞态窗口 - key 推荐格式：
"idempotent:{business_type}:{user_id}:{idempotency_key}"，比如"idempotent:pay:u123:abc456"，防止不同用户/接口互相干扰 - value 别存空字符串，建议填客户端传的
X-Idempotency-Key或 trace_id，方便日志对齐和人工排查 - TTL 设为「业务最长耗时 + 安全余量」，支付类设 3600 秒，普通操作设 300–900 秒；太短会误拒重试，太长会堆积无效 key
- Redis 故障时不能静默放行，必须返回
503 Service Unavailable，否则幂等语义彻底失效
数据库唯一索引作为不可绕过的兜底
Redis 可能宕机、网络可能超时、客户端可能绕过 header——所有中间层都可能失效，DB 层才是最后一道铁闸：
- 建联合唯一索引，例如
UNIQUE (user_id, idempotency_key)或UNIQUE (order_id, trace_id)，不是单列索引 - 插入幂等记录（如
idempotent_logs表）必须在业务逻辑执行前完成，且与主业务写入放在同一事务中 - 捕获唯一约束错误要精准：PostgreSQL 检查
pgx.ErrCodeUniqueViolation，MySQL 检查1062，别 catch 所有 error 后统一返回 success - 错误处理要区分：真失败（如余额不足）返回
400，已存在才返回200+ 原始结果，否则前端会反复重试
针对“先查后改”场景用 SELECT FOR UPDATE 加行锁
当业务逻辑依赖当前状态（比如“只有 pending 订单才能转 paid”），单纯缓存或唯一索引不够，得靠数据库行级锁堵住竞态窗口：
- 必须在同一个事务里完成：
SELECT ... FOR UPDATE→ 状态判断 →UPDATE ... WHERE id = ? - WHERE 条件必须命中索引，否则会升级为表锁，拖垮并发
- 事务里禁止 HTTP 调用、sleep、复杂计算，锁持有时间越短越好
- 不要用
SELECT ... FOR UPDATE NOWAIT简单报错，应配合有限重试（如最多 3 次，间隔递增）提升成功率
异步任务幂等：消息 + 幂等键 + 状态机
用户提交后触发发短信、扣库存、调第三方等异步动作，这些环节更要幂等，否则重试会导致多发、多扣：
- 消息体里必须携带幂等键（如
idempotency_key），消费者拉取后先校验是否已处理（查 DB 或 Redis） - 推荐用状态机控制：任务表加
status字段（pending/processing/success/failed），更新时用WHERE status = 'pending'保证只处理一次 - 避免裸用 goroutine 做异步——进程重启就丢任务；关键任务必须走 RabbitMQ/Kafka + 持久化 + 手动 ACK
- 第三方接口调用失败时，不要立即重试，先落库标记为 failed，由后台定时任务按策略补偿（如指数退避）
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
