Fiber 本身不内置防抖和幂等性控制，必须依赖中间件+Redis等外部存储实现；纯内存方案在多实例下必然失效。
直接说结论：Fiber 本身不内置防抖（debounce）和幂等性（idempotency）控制，必须靠中间件 + 外部状态存储（如 Redis）组合实现；纯内存方案在多实例部署下必然失效。
为什么不能只用 time.Sleep 或闭包变量做防抖
常见错误是写个闭包缓存上一次时间戳，每次请求比对间隔再决定是否放行。这在单进程单协程下看似可行，但实际会踩三个坑：
- Fiber 默认启动多协程（goroutine），
time.Sleep不阻塞整个服务，只阻塞当前请求协程——防抖逻辑完全失效 - 闭包变量是全局共享的，多个并发请求会互相覆盖
lastCallTime，导致误判 - 多实例部署时，每个实例维护独立状态，A 实例拦截了请求，B 实例仍会执行——根本没防抖
fiber.New() 启动前必须配置共享存储驱动
防抖与幂等都依赖「跨请求、跨实例」的状态一致性，必须接入外部存储。推荐顺序：
- 首选
Redis：支持原子操作（SET key value EX 60 NX）、过期自动清理、高吞吐 - 次选
PostgreSQL（带ON CONFLICT DO NOTHING）：适合已有数据库且对强一致性要求极高场景 - 禁用内存型方案（如
sync.Map）用于生产环境，仅限本地调试
示例初始化（使用 go-redis）：
client := redis.NewClient(&redis.Options{
Addr: "localhost:6379",
Password: "",
DB: 0,
})
// 预热连接
_, _ = client.Ping(context.Background()).Result()
幂等 Key 的提取必须包含业务语义，不能只用 req.Header.Get("X-Idempotency-Key")
单纯依赖客户端传的 header 是危险的。真实场景中应组合至少两项：
- 客户端显式传递的
X-Idempotency-Key（作为主键） - 请求 Body 的 SHA256 摘要（防止相同 key + 不同 payload 被误认）
- 可选：用户 ID 或租户 ID（避免跨租户冲突）
生成最终 key 的典型方式：
key := fmt.Sprintf("idempotent:%s:%x:%s",
c.Get("X-Idempotency-Key"),
sha256.Sum256([]byte(c.Body())),
c.Locals("tenant_id"))
注意：c.Body() 需提前调用 c.Request().Body 并重置，否则后续中间件读不到内容。
防抖中间件必须区分「拒绝」和「等待返回上一次结果」两种策略
很多团队混淆了「防抖」和「缓存响应」。真正的防抖（如防止重复提交订单）应直接拒绝；而「幂等」才需要返回历史结果。两者逻辑分离更安全：
- 防抖中间件：检查
key是否在窗口期内已存在 → 存在则返回429 Too Many Requests - 幂等中间件：检查
key是否已成功处理 → 是则返回原响应体（需提前落库记录 response body）；否则放行并记录
关键点：幂等结果存储必须包含完整 HTTP 响应（status code + headers + body），不能只存 status。
最易被忽略的是 Body 读取时机——Fiber 的 c.Body() 只能读一次，且必须在所有依赖 Body 的中间件之前完成解析并重置 Request.Body。否则防抖/幂等中间件拿到空内容，SHA256 摘要恒为固定值，整个机制崩塌。
