必须开启手动ack，否则prefetch无效；需配置acknowledge-mode: manual并显式调用basicack/nack；prefetch值应匹配单线程处理能力（如耗时200ms则设5）；@rabbitlistener级配置优先于全局配置；限流生效依赖manual ack、合理prefetch、显式ack、并发数四者闭环。

必须开启手动 ack，否则 prefetch 配置完全无效——这是 90% 限流失效的根源。

为什么 prefetch 不生效？手动 ACK 是硬门槛

限流依赖 RabbitMQ 的 QoS 机制，而该机制只在消息处于 “unacknowledged” 状态时起作用。如果使用自动 ACK（acknowledge-mode: auto），消息一送达就立刻被标记为已确认，Broker 会持续推送新消息，prefetch 形同虚设。

• Spring Boot 默认是 auto 模式，不改就等于没限流
• acknowledge-mode: manual 必须显式配置，且消费者代码中必须调用 channel.basicAck() 或 basicNack()
• 若忘记 ACK 或抛异常未捕获，消息会一直卡在 unack 状态，导致后续消息“堵死”，看似限流实则停摆

prefetch 值怎么设？不是越小越好

prefetch 是每个消费者线程的未确认消息上限，不是整个应用或队列的全局限制。设得太小（如 1）会导致吞吐骤降；设太大（如 100+）又起不到保护作用。关键看单线程处理能力。

• 压测出单个线程稳定处理的 QPS（比如 50 QPS），再结合平均处理耗时估算合理值：例如平均耗时 200ms，那 1 秒最多积压 5 条未确认消息 → prefetch: 5 较稳妥
• 若启用了多线程消费（concurrency: 5），总未确认上限 = 5 × prefetch，但各线程独立计数，互不影响
• prefetch: 0 表示不限制（等同于关闭限流），不要误配

全局配置 vs @RabbitListener 级别配置，哪个优先？

两者可共存，但 @RabbitListener 上的配置会覆盖 application.yml 中的全局配置，优先级更高。

RabbitMQ 4.2.3

RabbitMQ 4.2.3 是 2026 年初发布的重要稳定更新版本，重点修复了 Khepri 元数据存储相关问题，并改进了监控性能。对于使用 Docker、Kubernetes 或微服务架构的开发团队来说，该版本兼容性和稳定性表现较好。

下载

• 全局配置适合统一基线（如默认 prefetch: 10），写在 application.yml 里
• 对关键队列（如订单、支付）单独收紧限流，直接在监听器加参数：@RabbitListener(queues = "order.queue", prefetch = "3")
• 注意：prefetch 是字符串类型，必须加引号，否则 Spring Boot 2.3+ 会解析失败

容易被忽略的隐性瓶颈：消费者线程数与 prefetch 的协同

只调 prefetch 不调并发数，可能让单线程扛不住压力；只增并发不控 prefetch，又会让每条线程都堆积大量消息。

• 先固定 concurrency（如从 3 开始），压测出单线程极限，再定 prefetch
• 再逐步增加 max-concurrency，观察 Broker 的 unack 消息总数和消费者 GC 频率
• 特别注意：Spring Boot 默认使用 SimpleMessageListenerContainer，它会在高负载时动态扩容消费者，但扩容后每个新线程都会携带一份 prefetch 配额——总量可能远超预期

真正起作用的从来不是某个参数，而是 acknowledge-mode: manual + 合理 prefetch + 显式 ACK 调用 + 并发数匹配这四者闭环。漏掉任意一环，限流就只是配置文件里的一行静态文字。