ch.Consume()后不应多goroutine并发range msgs，因msgs是单channel，for range串行读取，多goroutine会竞争阻塞；正确做法是单goroutine range并分发msg至独立goroutine处理，同时注意拷贝msg.Body、单goroutine调Ack、exclusive=false、QoS限预取、Channel不跨goroutine复用。
ch.Consume()后直接for range msgs会卡死？别让goroutine抢光消息
很多人以为启动多个goroutine去处理msgs channel里的消息就能并发，结果发现：只有第一个goroutine在干活，其余全阻塞。这是因为msgs是单个Go channel，for range本身是串行迭代——你起10个goroutine同时range msgs，它们会竞争读取，但RabbitMQ的投递逻辑只往这一个channel里写，最终大部分goroutine永远等不到消息。
正确做法是：只用一个goroutine做for msg := range msgs，然后把每条msg扔进独立goroutine处理。但必须注意两点：
- 立即拷贝
msg.Body：data := append([]byte(nil), msg.Body)，否则下一轮循环msg内存可能被复用 - 每个goroutine处理完再调
msg.Ack(false)，别在主循环里统一ack——deliveryTag是per-channel单调递增的，跨goroutine乱序ack会触发PRECONDITION_FAILED - unknown delivery tag - 不要在goroutine里直接用原
msg调Ack/Nack，必须把msg或其关键字段（如DeliveryTag、Ack方法绑定的ch）显式传进去
多个消费者实例怎么分摊消息？exclusive=false + QoS是前提
想靠部署多个服务实例来水平扩容消费能力，却看到所有消息都跑到某一台机器上？大概率是ch.Consume()第四个参数exclusive设成了true。排他队列只能被创建它的连接独占，其他实例连不上这个队列，自然收不到消息。
必须确保：
立即学习“go语言免费学习笔记（深入）”；
-
exclusive: false（默认就是false，但建议显式写出） -
autoAck: false，否则RabbitMQ一发完就删消息，其他实例根本没机会争 -
ch.Qos(1, 0, false)——限制每个channel最多1个unacked消息。不设的话，某个实例可能预取几百条卡在内存里，别的实例饿死 - 队列声明时
durable: true且autoDelete: false，否则重启后队列消失，新实例Consume直接报NOT_FOUND
为什么goroutine越开越多，最后OOM？Channel不是线程安全的
有人为了“更并发”，在每个goroutine里都调一次conn.Channel()，再调ch.Consume()——这会导致大量channel对象堆积，内存涨得飞快，而且RabbitMQ服务端也会因过多channel连接而变慢甚至拒绝新请求。
更危险的是：复用同一个*amqp.Channel实例跨goroutine调ch.Publish()或msg.Ack()，会直接panic：send on closed channel或invalid memory address。因为*amqp.Channel内部有共享状态和非线程安全的buffer。
安全实践是：
- 生产者：每次发消息前
conn.Channel()，用完立刻ch.Close() - 消费者：整个消费循环（从
ch.Consume()到for range结束）共用一个ch，但业务处理扔goroutine；别在goroutine里再拿ch干别的事 - 全局只维护一个
*amqp.Connection单例，并配Heartbeat: 10 * time.Second防LB静默断连
限流不是QoS，单位时间处理数才决定是否过载
设了ch.Qos(5, 0, false)就以为能控并发？错。这只是告诉RabbitMQ：“我最多同时持有5条未确认消息”，但你的goroutine可能把这5条全丢进go process(data)，瞬间拉起50个HTTP请求——QoS完全不管这个。
真正要控的是处理速率，尤其当下游是数据库或第三方API时：
- 用
golang.org/x/time/rate在for msg := range msgs循环第一行加limiter.Wait(ctx) - 别把限流器放在
amqp.Dial()或ch.Consume()之前——那限的是建连或订阅动作，不是消息处理 - 如果处理逻辑含重试（比如HTTP失败后sleep再试），限流器必须包住整个重试块，否则重试本身会绕过限流
-
ctx带超时，避免某次Wait卡死导致整个消费协程挂住
deliveryTag复用、channel复用、QoS误当限流用——这三个点线上最容易出事故，修的时候往往要翻日志查半天才定位到根源。
