rabbitmq消费者重复消费是因“至少一次投递”设计所致，需通过redis+消息id实现幂等，而非依赖deliverytag、messageid或数据库唯一索引兜底。
为什么RabbitMQ消费者会重复收到同一条消息
不是RabbitMQ发错了，而是它设计上就允许“至少一次投递”——网络断开、消费者崩溃、ACK超时未返回，都会触发重发。你看到msg.Nack(false, true)把消息扔回队列，或ch.Qos(1, 0, false)没设好导致预取堆积，都可能让同一条msg.DeliveryTag被多次送到同一个或不同消费者进程里。
常见错误现象：日志里同一msg.MessageId（如果生产者设了）出现两次“已扣库存”，数据库订单表多出两条记录，但消费者代码里明明写了msg.Ack()。
- 别假设消息体自带的
MessageId一定唯一——AMQP协议不强制要求生产者设置，且部分客户端默认不生成 - 别依赖
msg.Redelivered字段判断是否重投——它只反映RabbitMQ层面是否重发过，不等于业务层是否已处理成功 - 消费者重启后，未ACK的消息会被RabbitMQ重新入队，此时
msg.DeliveryTag会变，无法靠它做去重
用Redis+消息ID实现消费幂等（推荐生产环境）
核心是把“消息已处理”这个事实持久化到外部存储，并保证检查+写入原子性。Redis是最常用选择，但必须用SET key value EX seconds NX一次性完成，不能拆成GET再SET。
消息ID建议组合生成：msg.ExchangeName + ":" + msg.RoutingKey + ":" + sha256(msg.Body)，避免仅用msg.MessageId被伪造或复用。
- key格式示例：
"mq:logs:error:" + hex.EncodeToString(sha256.Sum256(msg.Body).Sum(nil)) - 过期时间必须大于业务最大耗时（比如扣库存+写DB最长8s，设
EX 30） - 用
github.com/go-redis/redis/v9时，直接调rdb.SetNX(ctx, key, "done", 30*time.Second)，返回true才执行业务逻辑 - 若
SetNX返回false，说明已处理过，可直接msg.Ack()并跳过后续流程
为什么不能只靠数据库唯一索引兜底
数据库唯一约束（如在订单表加UNIQUE INDEX idx_msg_id (msg_id)）确实是最终防线，但它解决的是“写入阶段”的重复，而非“消费阶段”的重复——消息可能已触发下游HTTP调用、发邮件、推通知，这些副作用无法回滚。
更麻烦的是，两个消费者几乎同时通过Redis校验（极小窗口竞争），都拿到true，然后都去DB插入，这时唯一索引才会生效，但其中一条请求的副作用已经发生。
- 唯一索引只能防止数据写入重复，拦不住已发生的业务动作（如调第三方支付接口）
- PostgreSQL报
unique_violation、MySQL报ErrCodeDuplicateEntry时，必须查库确认该消息是否真已成功处理，不能直接返回错误 - 若DB插入失败但上游已扣款，需额外补偿逻辑——这已超出幂等消费范畴，属于事务一致性问题
sync.Map适合测试环境但别上生产
单机调试时用sync.Map存map[string]struct{}能快速验证逻辑，但生产环境必须换Redis。原因很实在：进程重启后sync.Map全丢，之前处理过的消息ID就失效；横向扩多个消费者实例时，各进程的sync.Map互不可见，完全失去去重意义。
如果你非要用内存方案，至少得加一层清理——比如用time.AfterFunc为每个key设5分钟过期，但这样仍无法解决扩容和故障恢复问题。
- 测试时key可简化为
string(msg.DeliveryTag)，但上线前必须换成带业务上下文的哈希值 -
sync.Map.LoadOrStore(key, struct{}{})返回的loaded布尔值才是判断依据，别只看Store结果 - 别在
sync.Map里存处理结果（如JSON），因为没过期机制，内存会持续增长直到OOM
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
