直接用普通map会导致并发panic且加锁易成瓶颈，应改用sync.Map本地快速判重+Redis跨实例幂等，key为"idempotent:token"并设TTL，value存状态，同时避免临界区耗时操作。
为什么直接用 map 做请求去重会出问题
并发场景下，多个 goroutine 同时读写一个普通 map 会触发 panic："fatal error: concurrent map writes"。哪怕加了 sync.Mutex，如果去重逻辑涉及网络 I/O（比如查 Redis）、或令牌校验耗时较长，锁持有时间一长就会成为瓶颈，甚至拖垮整个服务。
真正可行的方案是：用 sync.Map 处理本地快速判重（如秒级防重），再配合外部存储（如 Redis）做跨实例幂等；同时避免在临界区做耗时操作。
- 本地去重只存
token+ 过期时间戳，不存完整请求体 - 校验时先查
sync.Map，命中则直接返回；未命中再查 Redis，并把结果回填到sync.Map - Redis 的 key 设计为
"idempotent:<code>token"，value 存处理状态（"processing"/"done"/"failed"），并设 TTL（如 10 分钟）
如何生成和验证幂等令牌（Idempotency-Key）
客户端必须在每次请求头里带上 Idempotency-Key，服务端不能自动生成——否则无法保证“同一请求多次发送”能被识别为重复。
服务端只需校验该 token 是否已存在且状态为 "done"；若为 "processing"，可选择返回 409 Conflict 或阻塞等待（不推荐），更合理的是立即返回 425 Too Early 并提示重试。
- token 推荐用
crypto/rand.Read生成 16 字节以上随机字节，再 hex 编码成字符串 - 不要用时间戳、用户 ID 等可预测值拼接，否则易被绕过
- 验证逻辑必须原子：用 Redis 的
SET key value EX 600 NX尝试上锁；成功则继续处理，失败则查当前值判断是否已完成
sync.Map 和 Redis 协同时的竞态怎么破
典型竞态：goroutine A 查 sync.Map 未命中 → 查 Redis 得到 "done" → 正准备写回 sync.Map；此时 goroutine B 已完成同样流程并抢先写入，A 再写就覆盖了新状态，导致后续请求误判。
根本解法不是加锁，而是让 sync.Map 只缓存「确定已完成」的结果，且带时间戳版本控制：
- 每次从 Redis 读到
"done"后，只在sync.Map中存token → struct{ status string; ts int64 } - 写入前检查 ts 是否比已有值更新（用
CompareAndSwap或简单 if 判断） - 对
"processing"状态不缓存，避免本地缓存误导后续请求
HTTP 中间件怎么安全嵌入幂等逻辑
中间件必须在 body 读取前完成 token 提取和校验，否则 http.Request.Body 只能读一次，校验失败后无法交由下游处理。
常见错误是调用 io.ReadAll(r.Body) 后没重置，导致后续 handler 拿不到数据。正确做法是只读 header，或用 http.MaxBytesReader 限制大小后复制一份 buffer。
- 提取 token：从
r.Header.Get("Idempotency-Key")获取，空值或格式非法直接http.Error - 校验通过后，把 token 注入
context.WithValue透传给 handler，方便记录审计日志 - handler 执行完毕后，异步更新 Redis 状态（用
go func() { ... }()），避免阻塞响应
最易被忽略的是：Redis 状态更新失败时，没有 fallback 日志或告警机制——这意味着某次成功请求可能在后续被判定为重复，而你完全不知情。
