消息可靠投递需全链路控制：生产者开启Publisher Confirm并处理ACK/NACK、消息与队列/交换机均持久化、消费者禁用autoAck并手动确认、配合幂等去重。
在 Golang 微服务中，消息可靠投递不是“开了队列就完事”，而是要贯穿生产、传输、消费全链路的主动控制。核心不在选什么消息中间件，而在于是否正确启用并响应 ACK 机制——它才是防止消息丢失的真正开关。
生产者端：必须开启确认模式 + 处理返回结果
RabbitMQ 的 Publisher Confirm 是生产者侧防丢的第一道防线。不开启，Broker 即使崩溃，你也收不到任何失败信号。
- 调用
channel.Confirm()显式进入确认模式，否则所有发送都是“发完即忘” - 用
notifyPublishAck和notifyPublishNack监听每条消息的落盘结果，不能只看err（网络层成功 ≠ 消息已持久化） - 收到
Nack或超时未确认，必须触发重试逻辑；简单记录日志或忽略等于默认接受丢失 - 消息体本身需设置
DeliveryMode: amqp.Persistent，否则即使队列持久化，单条消息仍可能只存在内存中
队列与交换机：持久化不是可选项，是前提
ACK 只保证“Broker 收到了”，但如果 Broker 重启，没落盘的消息照样消失。持久化是 ACK 生效的基础条件。
- 声明队列时
durable: true，且队列名固定（避免每次启动创建新临时队列） - 声明 Exchange 时同样设
durable: true，否则绑定关系重启后失效 - Binding 关系本身无需单独持久化，但必须在 Exchange 和 Queue 都持久化的前提下建立
- 仅开启持久化还不够：RabbitMQ 集群建议配置镜像队列（
ha-mode: all），防止单节点故障导致数据不可用
消费者端：禁用自动 ACK，业务成功后再手动提交
很多丢消息问题其实发生在消费环节——自动 ACK 让消息在处理中途崩溃时直接被删除。
立即学习“go语言免费学习笔记（深入）”；
- 调用
channel.Consume(..., autoAck: false)，这是强制要求，不是优化项 - 处理逻辑必须包裹在
defer msg.Ack(false)或显式msg.Ack()前，确保只在业务函数返回 nil 后才确认 - 失败时不要静默跳过，应明确调用
msg.Nack(false, false)（拒绝且不重入队）或msg.Nack(false, true)（拒绝并重新入队），后者需配合死信队列（DLX）避免无限循环 - 建议搭配
channel.Qos(1, 0, false)限制预取数量，防止大量消息堆积在消费者内存中却未确认
补充保障：幂等性 + 去重是最终兜底
即使 ACK 全链路到位，网络重传或消费者重复拉取仍可能导致同一条消息被处理多次。这时靠的是业务层防御。
- 每条消息必须携带全局唯一 ID（如 UUID 或业务单号+时间戳组合）
- 消费者处理前先查去重表（Redis 或数据库），存在则直接跳过；不存在则先写入再执行业务逻辑
- 去重记录需设置合理 TTL（如 24 小时），避免存储无限膨胀
- 关键操作尽量设计为幂等：例如“扣减库存”改为“设置目标库存值”，“发通知”加状态字段判断是否已发
基本上就这些。不需要堆砌复杂框架，把 ACK 开启、持久化配对、手动确认写实、加上简单去重，95% 的消息丢失场景就能覆盖住。
