go程序高并发丢rabbitmq消息主因是端侧确认与持久化未对齐：生产者需开启publisher confirms并等待ack、消费者必须禁用auto-ack并手动ack/nack、channel需合理缓冲且三处持久化（交换器/队列/消息）缺一不可。
go 程序在高并发下丢 rabbitmq 消息，八成不是 broker 问题，而是生产者或消费者端的确认、持久化、channel 协作没对齐。关键不在“用没用 rabbitmq”，而在“ch.publish 调用后有没有等确认”、“ch.consume 后有没有手动 d.ack”、“ch.queuedeclare 的 durable 参数是不是 true”。
Go 生产者：不配 publisher confirms 就等于裸发
RabbitMQ 默认不保证生产者发出去的消息一定落地——哪怕 ch.Publish 返回 nil，也只代表 AMQP 帧写入成功，不代表消息进了队列。必须开启 publisher confirms 才能拿到 broker 的 ack/nack 回调。
-
ch.Confirm(false)必须在ch.Publish前调用，否则所有 publish 都不会触发 confirm - 每条消息要配唯一
correlationId（比如用uuid.NewString()），否则无法区分哪条失败 - 不要在 goroutine 里直接
ch.Publish后就扔掉——得用ch.NotifyPublish接收确认事件，超时未收到需重试或落库 - 若用
amqp.Publishing{DeliveryMode: amqp.Persistent}，但队列本身非durable，消息仍会丢失（broker 重启后队列消失）
Go 消费者：auto-ack = false 是底线，不是可选项
默认 ch.Consume(..., true, ...)（即 auto-ack = true）意味着只要消息一推给 consumer，RabbitMQ 就立刻删掉它。哪怕你的 goroutine panic、进程 kill -9、甚至 just forget to handle the message，消息都永远消失了。
- 必须设为
false：ch.Consume(q.Name, "", false, false, false, false, nil) - 处理完逻辑后，**必须且只能调一次**
d.Ack(false)；重复调用会触发ChannelError - 若处理失败，用
d.Nack(false, false)（不重入队）或d.Nack(false, true)（重入队），避免无限循环消费同一条坏消息 - 别在 defer 里写
d.Ack——万一 handler panic，defer 还是会执行，导致误确认
channel 与 goroutine 协作：别让缓冲区成“消息黑洞”
Go 客户端用 channel 接收 delivery（如 msgs := ch.Consume(...)），但这个 channel 本身不是 RabbitMQ 队列的镜像，只是个中转管道。它的容量、阻塞行为直接影响消息是否被丢弃。
- 如果
msgs是无缓冲 channel，而消费 goroutine 处理慢或卡住，RabbitMQ 会因“consumer unreachable”暂停投递，甚至触发 flow control，最终可能丢消息（尤其在 prefetch > 1 时） - 建议显式设缓冲：
msgs := make(chan amqp.Delivery, 100)，但别盲目设太大——内存爆了比丢几条更糟 - 务必监控
len(msgs)，接近 cap 时告警，说明消费能力已跟不上生产节奏 - 不要用
for range msgs+ 长时间 blocking 操作——应把 delivery 复制出来再处理，避免阻塞 channel 接收
持久化配置：三个地方都得打勾，缺一不可
消息不丢 ≠ 把 DeliveryMode 设成 Persistent 就完事。RabbitMQ 的持久化是“链式依赖”：交换器 → 队列 → 消息，三者任意一个没设 durable/persistent，整条链就失效。
- 声明交换器时加
amqp.Table{"durable": true}（虽然默认 true，但显式写更安全） - 声明队列时
ch.QueueDeclare(..., true, ...)第二个参数必须是true - 发布时
amqp.Publishing{DeliveryMode: amqp.Persistent, ...}——注意不是2，硬编码数字易出错 - 注意：即使全设了，若 broker 磁盘满、或启用了 lazy queue 但未配磁盘策略，仍可能丢（这时日志里会有
disk_failure相关错误）
最容易被忽略的是：publisher confirms 和 manual ack 是异步机制，它们的成功与否**无法通过函数返回值判断**。你得自己维护状态机、超时计时器、重试队列——这恰恰是 Go 高并发场景下消息可靠性的真正成本所在。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
