sync.Map 适用于小流量、单机、QPS 几百的幂等场景但无自动过期、不跨进程需用结构体缓存结果、定时清理、避免 key 污染Redis 需原子 SetNXEXDB 唯一索引为兜底。用 sync.Map 做单机幂等什么场景能用、什么情况会翻车小流量、单机部署、QPS 不超过几百时sync.Map 完全够用比 Redis 更快、零依赖。但它不是万能胶——它不支持自动过期也不跨进程。指纹 key 推荐拼成idempotent: method : path : clientID : idempotencyKey避免不同接口 key 冲突缓存值别存 bool得是结构体{status: success, result: json.RawMessage, timestamp: time.Time}否则“已存在”时你没法安全返回原始响应写入前必须先 Load命中就直接返回没命中才执行业务逻辑完成后必须 Store不能只靠 if 判断自己配定时清理比如每分钟扫一次 timestamp 超过 10 分钟的项或按需淘汰如 map size 10000 就删最老的 10%别在 handler 里裸用 sync.Map —— 并发请求共享同一个 map 实例没问题但 key 构造逻辑如果混了 context 或临时变量容易污染redis.Client.SetNX 必须带 NX 和 EX拆成两条命令就是埋雷用 Redis 做分布式幂等核心就一条原子性判断 自动过期。漏掉任一环节轻则缓存爆满重则服务雪崩。绝对不要先 EXISTS 再 SET中间有竞态窗口也别 SETNX 后补 EXPIRE万一第二步失败key 就永久卡住正确姿势是rdb.Set(ctx, key, value, ttl).AddArgs(NX, EX, 300)v9 客户端或直接用封装好的 SetNX(ctx, key, value, ttl)TTL 时间得大于接口最长耗时 网络抖动余量比如支付回调可能卡 45 秒TTL 至少设 60 秒value 别用空字符串建议存客户端传的 X-Idempotency-Key 或 trace_id方便日志对齐和人工排查Redis 连接失败时不能 fallback 到“放行”得返回 503 Service Unavailable否则幂等语义就崩了数据库唯一索引不是可选项而是兜底铁律所有中间层幂等控制都可能失效缓存击穿、Redis 故障、客户端绕过 header、网络重传……DB 层才是最后一道不可绕过的防线。 ARTi.PiCS ARTi.PiCS是一款由AI驱动的虚拟头像生产器可以生成200多个不同风格的酷炫虚拟头像