Iris框架需手动实现幂等性：优先从请求头提取Idempotency-Key，为空时依次fallback至JSON body字段或业务唯一字段组合；必须使用Redis SET key value EX 3600 NX原子操作校验，避免GET+SET竞态；校验失败返回409 Conflict，不缓存响应体。
Iris 框架没有内置幂等性支持，必须自己用 Redis + 原子操作搭，否则并发请求会绕过校验。
怎么从请求中安全提取 Idempotency-Key
客户端应优先在请求头带 Idempotency-Key，但不能只信它——得做 fallback 链路：
- 先读
ctx.Request().Header.Get("Idempotency-Key")，非空则直接使用 - 为空时，检查是否已解析过 JSON body（
ctx.ReadJSON()不能重复调），若已解析，尝试取idempotency_key字段 - 仍为空，可退化为拼接业务字段（如
user_id:order_id），但该组合必须天然唯一、不可被用户篡改（比如不能含前端传的 timestamp） - 不建议 fallback 到 UUID 或时间戳生成 key，那等于没做幂等
为什么必须用 SET ... NX + EX 而不是 GET + SET
Redis 的 GET 和 SET 是两个独立命令，中间存在竞态窗口。两个并发请求同时 GET 返回空，都会继续执行业务逻辑，导致重复提交。
正确做法是用原子命令：
redisClient.Set(ctx, "idempotent:"+key, "1", 3600*time.Second).Val()
注意返回值：.Val() 是 string 类型，要判断是否为 "OK"；如果返回 "OK" 表示首次写入成功，可继续处理；否则说明已存在，应拦截。
别用 redisClient.Exists()，它和后续操作无法构成原子性。
拦截后返回 409 还是复用上次响应
绝大多数场景推荐直接返回 409 Conflict 并附带提示（如 {"error": "request already processed"}）：
- 实现简单，无状态，不依赖额外缓存响应体
- 避免缓存污染：如果上次响应含动态字段（如时间戳、token），复用会导致语义错误
- 降低 Redis 内存压力：不用存 response body，key 只需存标记位
只有极少数对响应一致性要求极高、且响应体完全静态的接口（如配置查询），才考虑用另一个 key 存 idempotent:response:{key}，但要严格控制 TTL，且注意清理逻辑。
容易被忽略的边界点
真正上线后出问题的，往往不是主干逻辑，而是这些细节：
-
Idempotency-Key大小写敏感，Nginx 或 API 网关可能默认转小写，需确认 header 是否被修改 - Redis 连接池超时或故障时，不能直接 panic 或跳过校验——得降级为日志告警 + 允许通过（否则雪崩）
- POST/PUT 接口要做幂等，但 GET/DELETE 天然幂等，加了反而增加 Redis 压力，别滥用
- 测试时用
curl -H "Idempotency-Key: abc123"手动发两次，比写单元测试更快暴露原子性漏洞
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
