防抖动是前端概念，后端需通过幂等性设计解决重复请求问题；必须分三层防御：redis原子占位、db联合唯一索引、redis不可用时返回503；key须含业务上下文并正则校验；状态机应区分pending/success/failed，禁用sync.map。
防抖动（debounce）是前端概念，后端没有“接口防抖动”这回事；你真正要解决的是「重复请求导致的重复执行」，核心手段是幂等性设计，不是防抖。
为什么不能用前端防抖代替后端幂等
前端防抖只拦得住用户手抖连点，拦不住：Nginx/Envoy 的超时重试、客户端网络中断后自动重发、Service Mesh 的重试策略、消息队列重复投递、甚至 curl 手动重放。这些请求都带相同 X-Idempotency-Key，但服务端若没校验，照样执行两次。
- HTTP 协议不承诺“最多一次交付”，重试是基础设施默认行为
- Go 的
http.HandlerFunc无状态，不会记住上一个请求 - 把防抖逻辑放在前端，等于把一致性责任甩给不可控环境
Go 中必须落地的三道防线
单靠 Redis 或单靠 DB 都会翻车。真实线上环境需要分层防御：
-
第一道（快）：用
rdb.SetNX(ctx, key, traceID, ttl)原子占位，key必须拼业务上下文，例如"idempotent:pay:u1001:pay_abc123"，ttl≥ 接口最长耗时 + 30s 余量 -
第二道（稳）：业务 DB 表加联合唯一索引，如
UNIQUE (user_id, idempotency_key)，插入失败时捕获mysql.MySQLError.Number == 1062或pgx.ErrCodeUniqueViolation -
第三道（兜）：Redis 不可用时，
err != nil必须返回503 Service Unavailable，绝不能 fallback 到“放行”
容易被忽略的 key 构造陷阱
直接用客户端传的 X-Idempotency-Key 当 Redis key 是危险的——它不带业务上下文，会导致跨用户/跨接口误拦截或漏判：
- 两个用户都传
abc123，一个被拒，另一个也失败 → 错误扩散 - 同一用户在不同接口（如支付和退款）用相同 key → 互相污染
- 正确做法：
"idempotent:" + business_type + ":" + user_id + ":" + idempotencyKey，例如"idempotent:refund:u1001:ref_abc123" - 必须正则校验：
^[a-zA-Z0-9_-]{12,64}$，空值直接http.Error(w, "missing Idempotency-Key", http.StatusBadRequest)
状态机比布尔字段关键得多
只存一个 is_executed bool 字段，无法区分“正在执行中”和“已成功”，并发请求会卡死或错误返回：
- 首次请求：尝试写入
status = "pending"，成功才执行业务逻辑 - 执行完成：CAS 更新为
"success"或"failed"，value 存完整响应 JSON 和时间戳 - 后续请求命中
"pending"状态，可选择等待或返回 409，避免无限阻塞 - 别用
sync.Map替代状态机——它不跨进程、无自动过期、无法做 CAS
最常被跳过的环节是 DB 唯一索引和 Redis 故障时的 503 返回；只要漏掉其中一个，资金类接口就可能出双扣款。幂等不是“做了就行”，而是每一层都得严丝合缝。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
