不能直接用amqp.Consume启一堆goroutine，因多个goroutine竞争同一阻塞channel且AMQP不保证并发投递顺序；QoS按Channel而非goroutine级别生效，吞吐受限；应为每个goroutine独占一个Channel并各自Consume，合理设置Qos并用WaitGroup+Context统一管理生命周期。
为什么不能直接用 amqp.Consume 启一堆 goroutine？
因为 amqp.Consume 返回的是一个阻塞的 <-chan amqp.Delivery，它底层复用同一个 TCP 连接和 Channel，**多个 goroutine 从同一个 channel 接收会竞争，但 AMQP 协议本身不保证并发投递顺序或负载均衡**。更关键的是：RabbitMQ 的 QoS（basic.qos）是按 Channel 级别设置的，不是按 goroutine 级别——你启 10 个 goroutine 消费同一个 amqp.Consume 返回的 channel，实际仍只受单个 Channel 的 prefetchCount 限制，吞吐根本上不去。
真正高吞吐的做法是：**每个 goroutine 独占一个 AMQP Channel，并各自调用 Channel.Consume 订阅同一队列**（需开启 noLocal: false，默认即可）。这样每个 Channel 都能独立设置 Qos，RabbitMQ 也会把消息轮询分发到不同 Channel 上。
- 必须为每个 worker 创建独立
*amqp.Channel，不能复用连接上的同一个 Channel - 连接（
*amqp.Connection）可以复用，但 Channel 要按需新建；太多 Channel 会占用服务端资源，建议上限控制在 10–50 个，视队列压力和机器 CPU 核数调整 - 务必调用
channel.Qos(prefetchCount, 0, false)，例如qos(10, 0, false)表示最多 10 条未确认消息，这是提升吞吐的核心参数
如何安全管理多 Channel + Goroutine 生命周期？
手动启停几十个 goroutine 容易漏 defer、panic 传播失控、Channel 关闭竞争。推荐用 sync.WaitGroup + context.Context 统一控制退出，每个 worker 封装成函数并监听 ctx.Done()。
关键点：
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- worker 内部用
for { select { case d, ok := 结构，避免在 channel 关闭后继续读取 panic - 每个 worker 在启动前先调用
channel.Qos()，再调用channel.Consume()，顺序不能反 - 关闭时先 cancel context，再逐个
channel.Close()，最后conn.Close()；注意channel.Close()是线程安全的，可并发调用 - 不要在 worker 里 recover panic——应该让顶层监控捕获，否则失败消息会静默丢失
Delivery.Ack 失败会导致重复消费，怎么降低风险？
RabbitMQ 的 auto-ack=false 模式下，必须显式调用 d.Ack(false) 才算成功消费。但网络抖动、Channel 中断时，Ack 可能返回 Exception: channel error，此时 delivery 会重回队列（requeue=true 默认行为），造成重复。
缓解方式不是“重试 Ack”，而是：
- 在处理业务逻辑前，先持久化 delivery 的关键字段（如
d.MessageId、d.Headers、d.Bodyhash）到本地 DB 或 Redis，加唯一索引；后续消费前先查是否已处理 -
Ack调用必须带multiple=false（单条确认），避免批量确认时某条失败导致整批回滚 - 绝不使用
d.Nack(true, true)（requeue=true），这等于主动制造重复；出错时优先d.Reject(false)（丢弃）或发到死信交换机 - 确保
Qos中的global=false（默认），否则跨 Channel 的 prefetch 语义会混乱
性能瓶颈常卡在哪儿？几个典型陷阱
压测时发现吞吐上不去，90% 不是代码写得不够“并发”，而是被以下细节卡住：
- MySQL/Redis 等下游依赖没做连接池或超时设得太长，一个慢查询拖垮整个 goroutine，导致 RabbitMQ 积压；建议所有 I/O 操作都加
ctx.WithTimeout() - log.Printf 直接打屏或写文件，在高并发下成为 syscall 瓶颈；换成结构化日志库（如
zerolog）并异步刷盘 - 误把
json.Unmarshal放在 for-select 外层，导致所有消息共用一个map[string]interface{}，引发 map 并发写 panic；每个 delivery 必须 new 新结构体或用sync.Pool - 忘记设置 TCP KeepAlive 和 AMQP heartbeat（连接创建时传
amqp.Config{Heartbeat: 10 * time.Second}），长连接被中间设备静默断开，worker 陷入假死
真正决定吞吐的，从来不是 goroutine 数量，而是每条消息的平均处理延迟、Channel 级 QoS 设置、以及下游依赖的响应水位。调优时先看 rabbitmqctl list_channels 的 unconfirmed 和 prefetch 值是否匹配预期，再查 consumer 端 GC 和系统 load。
