go微服务中幂等性需三道防线：redis setnx（含业务上下文的key+正则校验）、db唯一索引兜底、故障时返回503；限流用rate.limiter保护资源，防抖需漏桶而非令牌桶。
Go 微服务里没有“接口防抖”这回事——前端防抖拦不住 Nginx 重试、Service Mesh 重发、curl 手动重放；你真正要解决的是「重复请求导致的业务重复执行」和「突发流量压垮服务」，前者靠幂等性，后者靠限流。两者必须分开设计，不能混用。
为什么不能用 golang.org/x/time/rate.Limiter 做防抖
rate.Limiter 是令牌桶，不是漏桶。它允许突发：100 QPS 配置下，前 10ms 可能放行 50 次请求，后 990ms 完全堵死。这对“防抖”毫无意义——你想要的是匀速、可预测的请求节拍，比如“每秒最多处理 10 个支付请求，严格排队，不堆积、不突增”。
- 令牌桶适合保护下游资源（如 DB 连接池），但不适合控制用户行为节奏
- 漏桶才匹配“防抖语义”：请求来了就进桶，按固定速率漏出，超容直接拒绝
-
rate.Limiter.Reserve()返回的是Delay()，不是布尔结果，无法做同步阻断
漏桶必须请求驱动，不能起 time.Ticker
常见错误是启一个 goroutine 每 10ms 调用一次 leak() 更新水位。这会导致三类线上问题：
- 高并发时大量 goroutine 竞争调度器，
runtime.scheduleCPU 占用飙升 - 两个请求在 Ticker 刚漏完后几乎同时到达，都看到“桶空”，误判为可进
- 浮点累加误差随运行时间放大，几小时后水位严重失真
正确做法是每次调用 Allow() 时，用 atomic.LoadInt64 读取 lastLeakTime 和 water，按 now - lastLeakTime 惰性计算漏水量，再用 atomic.CompareAndSwapInt64 原子更新——整个过程无锁、无 goroutine、无浮点。
幂等性不是可选项，而是三道防线的组合
只靠 Redis SetNX 或只靠 DB 唯一索引，都会在线上翻车。真实场景必须分层：
- 第一道（快）：
rdb.SetNX(ctx, "idempotent:pay:u1001:pay_abc123", traceID, 60*time.Second)，key 必须含业务类型 + 用户 ID + 客户端传的X-Idempotency-Key，且需正则校验^[a-zA-Z0-9_-]{12,64}$ - 第二道（稳）：DB 表加
UNIQUE (user_id, idempotency_key)，捕获mysql.MySQLError.Number == 1062或pgx.ErrCodeUniqueViolation - 第三道（兜）：Redis 不可用时，
err != nil必须返回503 Service Unavailable，绝不能 fallback 到“跳过校验”
状态机字段不能只存 is_executed bool——它无法区分 “正在执行中” 和 “已成功”。必须用字符串状态："pending" / "success" / "failed"，并配合 CAS 更新。
节流与幂等性必须隔离部署
节流是网关层或中间件层的事，作用对象是 IP 或 client_id；幂等性是业务 handler 层的事，作用对象是 X-Idempotency-Key。两者 key 空间、生命周期、存储位置完全不同：
- 节流 key 示例：
throttle:ip:192.168.1.100，TTL 通常 60s，用 Redis INCR + EXPIRE 实现 - 幂等 key 示例：
idempotent:refund:u1001:ref_abc123，TTL ≥ 接口最长耗时 + 30s，必须原子写入 - 若把幂等 key 当节流 key 用，会导致不同用户的退款请求互相阻塞
最易被忽略的是：幂等 key 的业务上下文拼接和正则校验——漏掉任意一项，轻则跨用户污染，重则被恶意构造 key 绕过校验。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
