必须结合 redis 原子占位 + db 唯一索引兜底，且所有环节适配 fiber 上下文模型：用 ctx.context() 透传幂等标识，redis setnx 原子设值带 ex，db 冲突后精准查状态返回结果，禁用 locals/sync.map 主存储。
直接用 Fiber 框架做接口幂等，不能只靠中间件存个 sync.Map 或简单校验 X-Idempotency-Key 头——它不跨实例、无自动过期、重启即丢，线上高并发下必翻车。必须结合 Redis 原子占位 + DB 唯一索引兜底，且所有环节都要适配 Fiber 的上下文模型和生命周期。
怎么在 Fiber 中安全透传幂等标识
Fiber 的 ctx 不是标准 context.Context，但 v3 已支持 ctx.Context() 方法返回原生 context，这是唯一能安全穿透中间件与 handler 的通道。别用闭包、全局变量或 ctx.Locals 存 key——Locals 是请求级 map，但并发时若 key 构造逻辑依赖临时变量（比如从 ctx.Query("t") 取时间戳），就会污染。
- 中间件里统一取头：
idempotencyKey := ctx.Get("X-Idempotency-Key")，为空直接return ctx.Status(400).SendString("missing X-Idempotency-Key") - 正则校验格式：
^[a-zA-Z0-9_-]{12,64}$，防注入和非法长度 - 拼业务上下文构造 Redis key：
fmt.Sprintf("idempotent:%s:%s:%s", "order_create", userID, idempotencyKey)，其中userID从 JWT 或 session 解析，不裸用客户端传值 - 塞进原生 context：
newCtx := context.WithValue(ctx.Context(), "idempotent_key", key)，后续 handler 通过ctx.Context().Value("idempotent_key")拿
Redis.SetNX 必须原子执行且带 EX，Fiber 中怎么写才不出错
Fiber 本身不封装 Redis 调用，你得自己集成 redis-go 客户端（推荐 v9）。常见错误是把 SETNX 和 EXPIRE 拆成两步，或用 Exists + Set 判断——这在并发下必然穿透。v9 的 rdb.SetNX 是正确入口，但要注意参数顺序和返回值语义。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 调用姿势：
ok, err := rdb.SetNX(ctx.Context(), key, traceID, 300*time.Second).Result()，ok == false表示 key 已存在（不是错误），err != nil才是连接异常 - TTL 时间必须 ≥ 接口最长耗时 + 安全余量，比如订单创建含库存扣减+发券+消息投递，实测最长 82s，TTL 至少设 120s
- value 建议填
traceID（从ctx.Get("X-Trace-ID")取）或原idempotencyKey，别存空字符串，方便日志对齐 - Redis 故障时，
err != nil必须返回ctx.Status(503).SendString("Service Unavailable")，绝不能 fallback 到执行业务逻辑
Fiber handler 里怎么衔接 DB 唯一索引兜底
Redis 校验通过后进入业务逻辑，此时 DB 是最后一道防线。别在事务里查 Redis 状态，也别用 SELECT ... FOR UPDATE 去“先查再插”——这既慢又可能死锁。唯一索引必须是联合的、业务语义明确的，并且冲突后要精准识别、主动查询确认结果。
- 建表索引示例（MySQL）：
UNIQUE INDEX idx_user_id_idempotency_key (user_id, idempotency_key)，字段顺序和类型必须与代码中拼接一致 - 插入失败后，捕获具体错误：
if mysqlErr, ok := err.(*mysql.MySQLError); ok && mysqlErr.Number == 1062 - 捕获到冲突，立刻查 DB：
SELECT status, result_json FROM idempotent_records WHERE user_id = ? AND idempotency_key = ?，确认是否真已成功；状态字段必须是 enum（pending/success/failed），不能只存 bool - 查到
success就直接返回缓存结果（含原始 HTTP 状态码和 body），别重复序列化 - 查不到或状态为
pending，说明是 Redis 误判或 DB 写入失败，需人工介入，不能自动重试
为什么不能用 Fiber 的 ctx.Locals 或 sync.Map 做幂等主存储
ctx.Locals 生命周期只到 handler 结束，没法跨中间件共享状态；sync.Map 在单机场景下看似快，但它不支持过期、不跨进程、重启即丢——而 Fiber 应用通常多实例部署，K8s 里 Pod 随时重建。这两个方案单独用，等于没做幂等。
-
sync.Map缓存值必须是结构体：{status: "success", statusCode: 201, body: []byte(...), timestamp: time.Now()}，否则命中后无法还原原始响应 - 自己实现定时清理：启动 goroutine 每 30 秒扫一次，删
timestamp.Before(time.Now().Add(-10 * time.Minute))的项 - 但仅限开发环境或 QPS
- 如果硬要用
sync.Map，key 构造必须排除任何非稳定字段（如ctx.IP()、time.Now()），否则不同请求会互相覆盖
最易被忽略的一点：幂等结果缓存必须包含完整 HTTP 响应（状态码 + header + body），而不是只存业务数据。因为前端重试时，服务端返回 201 还是 200、是否有 Location header，都影响下游行为——这个细节在 Fiber 里尤其关键，它的 ctx.SendStatus() 和 ctx.JSON() 不共享序列化逻辑，必须手动缓存原始字节。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
