prefetchCount过大会导致消费者本地未ACK消息堆积并引发内存压力。具体表现为：RabbitMQ按该值批量推送消息至消费者TCP缓冲区及Go内存，若处理慢或ACK延迟，消息因被goroutine栈、channel等强引用而无法被GC回收；单条10KB消息配prefetch=1000即占10MB，5个consumer达50MB；global=true时更危险，多个consumer共享上限易致分配不均、首个consumer OOM；真实内存压力取决于unacked数×平均消息大小×并发consumer数，需通过rabbitmqctl与top命令联合验证调优效果。
prefetchCount 过大会让未 ACK 消息在消费者本地堆积
go 客户端（比如 streadway/amqp）调用 channel.qos(prefetchcount, 0, false) 后，rabbitmq 会按该值向这个 consumer 预分配消息 —— 不是“发一条、等一条”，而是“一次推多条进 tcp 缓冲区 + 客户端内存”。这些消息一旦到达 go 程序，就会被解码成 amqp.delivery 结构体，存入 channel 或 goroutine 的局部变量中。如果处理慢、ack 延迟，它们就卡在内存里不释放。
Go runtime 不会自动 GC 这些“活引用”的消息对象
常见误区是以为“没处理完就等着，GC 会收掉”。但只要消息还在 goroutine 的栈上、或被某个 map/slice/channel 引用着（比如你用 make(chan amqp.Delivery, 1000) 缓存 Delivery），Go 就认为它是活跃对象。尤其当 prefetchCount 设为 1000，而每条消息平均 10KB，光 Delivery 结构体+消息体就能占 10MB 内存；若并发 5 个 consumer，瞬间就是 50MB —— 还没算业务逻辑里数据库连接、JSON 解析、临时切片的开销。
global = true 时更危险：多个 consumer 共享同一上限
如果你误用了 channel.Qos(1000, 0, true)，那这个 1000 是整个 channel 上所有 consumer 共享的未 ACK 总数。假设你启了 10 个 goroutine 调用 channel.Consume，RabbitMQ 可能一口气把 1000 条全塞给第一个 consumer（AMQP 协议允许这种非均匀分发），其余 9 个 consumer 空转，而第一个早已 OOM。这不是理论风险 —— 在高吞吐场景下，global = true 实际等于关闭了 per-consumer 流控。
真正要盯住的不是 prefetchCount 数值，而是 unacked × 平均消息大小 × 并发 consumer 数
内存压力来自三者的乘积，不是单看一个参数。例如：
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
- 消息平均 200KB，prefetchCount = 50，单 consumer → 理论峰值内存 ≈ 10MB
- 同一 channel 启 8 个 consumer，且 global = false → 最坏情况每个都拿满 50 条 → 峰值 ≈ 80MB
- 若其中某 consumer 因 DB 锁卡住 30 秒未 ACK，这 80MB 就持续驻留
所以线上调参前，先用 rabbitmqctl list_queues name messages_unacknowledged 和消费者进程的 top -p $(pidof your-app) 对齐真实内存占用和 unacked 数量 —— 很多团队只改了 prefetch，却忘了查 unacked 是否真降下来了。
立即学习“go语言免费学习笔记（深入）”；
