RabbitMQ消费者必须关闭autoAck以避免消息丢失，应设autoAck=false并手动调用msg.Ack()或msg.Nack()；需配合QoS限流、死信队列和消息持久化保障可靠性；连接应复用而Channel需每goroutine独立创建。
为什么 RabbitMQ 消费者必须关掉 autoAck
因为开 autoAck=true 时，RabbitMQ 一发消息就立刻从队列删掉——哪怕你的 Go 程序刚收到还没开始处理、或者处理中途 panic、网络断了、进程被 kill，消息就永久丢失了。这不是“可能丢”，是“一定丢”。
- 真实场景里，
processMessage()往往涉及数据库写入、HTTP 调用、文件 IO，这些都可能失败或超时 -
ch.Consume()第三个参数必须是false（即autoAck=false） - 手动 ACK 才是唯一能保证“处理成功才删消息”的方式
msg.Ack() 和 msg.Nack() 怎么调用才安全
每条 msg 收到后，必须且只能调用一次 msg.Ack(false) 或 msg.Nack()；忘记调用、重复调用、在 goroutine 外调用（比如 defer 里），都会导致连接卡死或消息堆积。
- 业务逻辑 panic 时，需
recover并显式msg.Nack(true, false)，否则该 delivery tag 会一直阻塞后续消息 -
msg.Nack(requeue, multiple)：日常重试只用msg.Nack(true, false)（消息重新入队）；requeue=false会直接丢弃，除非你配了 DLX，否则进黑洞 - ACK/NACK 必须在同一个
amqp.Channel上调用；跨 goroutine 传递amqp.Delivery时别漏传ch
消费者怎么配合 QoS 和死信兜底防雪崩
不设预取限制，一个慢消费者可能把几千条消息全拉进内存，其他实例饿死；不配死信，Nack(false, false) 或处理失败没兜底，消息就消失了。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 用
ch.Qos(1, 0, false)控制预取数（prefetch count），推荐从 1 开始调优，避免单点积压 - 声明队列时必须加参数：
args: amqp.Table{"x-dead-letter-exchange": "dlx.exchange"} - 确保死信交换器已存在，并绑定好死信队列，否则
Nack(false, false)后消息直接丢弃 - 消息本身也要持久化：发布时设
DeliveryMode: amqp.Persistent，否则即使队列 durable，消息仍可能因 Broker 重启丢失
微服务中复用连接和 Channel 的坑在哪
amqp.Connection 是重量级资源，不能每次消费都 amqp.Dial() 再 conn.Close()——这会导致连接风暴、端口耗尽；但 Channel 又不是线程安全的，全局复用会出竞态。
立即学习“go语言免费学习笔记（深入）”；
- 连接必须单例或依赖注入管理，配置
Heartbeat: 10 * time.Second防 K8s 网络策略掐空闲连接 - 每个 goroutine 应自己调用
ch, _ := conn.Channel()，用完立刻ch.Close() - 队列声明参数要对齐语义：
durable:true（重启不丢元数据）、autoDelete:false（滚动更新时不被删）、exclusive:false（支持多实例）
ACK 不是收尾动作，是控制流决策点；error 不是日志里的字符串，是决定消息命运的开关。很多人把 if err != nil 后只打日志，等于默认丢弃消息——而 RabbitMQ 不会提醒你它已经静默消失。
