最稳的分布式幂等方案是Redis+Lua原子校验：用EVAL执行脚本，先GET再SETEX，避免并发漏判；key需含业务类型、操作类型、主键并设过期时间；唯一索引和sync.Map均不可靠。用 Redis + Lua 实现原子性幂等校验Go 分布式幂等最稳的路子，是把「判断是否已处理」和「记录已处理状态」合并成一个原子操作，否则并发时必然漏判。Redis 的单线程特性和 EVAL 支持让这事变得可靠。常见错误是先 GET 再 SET：两个命令之间存在时间窗口，多个请求同时读到空值，全都会往下走，导致重复执行。用 EVAL 执行一段 Lua 脚本，检查 key 是否存在；不存在则 SET 并返回 1，存在直接返回 0key 建议用业务唯一标识拼接，比如 "idempotent:order_create:" + orderId，避免不同接口互相干扰务必设过期时间（EX），否则失败后 key 永久残留，后续请求全被拒示例脚本：if redis.call("GET", KEYS[1]) == false then redis.call("SET", KEYS[1], "1", "EX", ARGV[1]) return 1else return 0end为什么不能只靠数据库唯一索引唯一索引能拦住写入重复，但拦不住业务逻辑重复执行——比如扣库存、发消息、调第三方接口这些动作，在插入失败前已经发生了。典型场景：用户连点提交按钮，两次请求都走到 DB 插入前，其中一次成功插入，另一次报 ERROR: duplicate key value violates unique constraint，但前者早已发了短信、减了余额。立即学习“go语言免费学习笔记（深入）”； 文心快码 文心快码（Comate）是百度推出的一款AI辅助编程工具