ch.Consume() 必须设 autoAck: false 才能手动确认消息，避免自动确认导致丢失；exclusive 应为 false 以支持多消费者；noWait 用 false 防静默失败；args 可为 nil 或配置 QoS。
ch.Consume() 的参数怎么配才不丢消息
默认配置下，ch.Consume() 很容易让消息“悄无声息地消失”——不是没收到，而是被自动确认后丢了，你根本来不及处理。关键在第三个参数 autoAck：设成 true 表示 RabbitMQ 一发完就当消费成功，哪怕你的 Go 程序 panic 或还没解析完 body；设成 false 才能手动控制确认时机。
-
autoAck: false是可靠消费的前提，必须显式写出来 - 第四个参数
exclusive推荐设为false，否则队列只能被当前连接独占，没法做多消费者扩容 - 第五个参数
noWait一般用false，避免因服务端拒绝而静默失败 - 最后一个
args可传nil，但若需设置 QoS（比如限制未确认消息数），得用amqp.Table{"x-priority": 10}这类键值
收到消息后，怎么确认才真正安全
用了 autoAck: false，就得自己调 msg.Ack(false) 或 msg.Nack(false, true)，但别急着在 for range msgs 循环里直接调 —— 这是高频翻车点。RabbitMQ 的 msgs 是一个 channel，消息体 msg.Body 的内存只在本次循环生命周期内有效；一旦下一次迭代开始，上一条的 msg 就可能被复用或释放。
- 必须把
msg.Body拷贝出来再处理，比如data := append([]byte(nil), msg.Body...) - 确认操作要放在业务逻辑执行完之后，且只在成功时调
msg.Ack(false) - 出错时别漏掉
msg.Nack(true, false)（重入队）或msg.Reject(true)（丢弃），否则消息会卡在 unacked 状态 - 不要在 defer 里调
Ack，defer 触发时机不可控，容易在 panic 后误确认
为什么 consumer 一跑就断连？常见心跳和超时陷阱
RabbitMQ 默认 60 秒无响应就主动断开连接，而 Go 的 amqp 客户端不会自动发心跳帧。如果消费逻辑里有长耗时操作（比如 HTTP 请求、数据库事务），或者用了 time.Sleep 模拟延迟，很容易触发连接被 server 强制关闭，日志里看到 read: connection timed out 或 Broken pipe。
- 初始化连接时加心跳参数：
amqp.Dial("amqp://guest:guest@localhost:5672/?heartbeat=30") - 确保
ch.Consume()后的 for 循环不阻塞，所有耗时操作扔进 goroutine，但注意并发安全和资源泄漏 - 别依赖
conn.IsClosed()判断连接状态，它返回的是本地缓存值；真要检测，得靠conn.NotifyClose()监听事件 - Channel 层面也要防死锁：如果
ch.Publish()在另一个 goroutine 频繁调用，而 consumer 侧没及时 Ack，可能触发 RabbitMQ 的 flow 控制，让整个 Channel 卡住
如何让 consumer 支持优雅退出
Ctrl+C 一按，程序直接 exit，正在处理的消息既没 Ack 也没 Nack，RabbitMQ 会等一段时间后把它放回队列（requeue），但下次谁来消费？如果没做幂等，重复处理就来了。真正的“优雅”是：收到信号后停止收新消息，处理完手上这条再退出。
立即学习“go语言免费学习笔记（深入）”；
- 用
signal.Notify(sigChan, os.Interrupt, syscall.SIGTERM)捕获退出信号 - 在 for 循环里 select 监听
msgs和sigChan，收到信号后 break 出循环 - 退出前调
ch.Cancel(consumerTag, false)告诉 RabbitMQ “我不再消费了”，避免消息被分给已退出的 consumer - 最后记得
conn.Close()和ch.Close()，否则连接泄漏会让 RabbitMQ 的 socket 数持续上涨
最麻烦的不是写几行 Ack，而是把“消息生命周期”和“Go goroutine 生命周期”对齐——消息从抵达、解包、处理、确认，到连接断开、重连恢复，每个环节都有状态漂移风险。留心那些没报错却悄悄丢失的 case，它们往往藏在 autoAck 和 defer 的组合里。
