必须开启手动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 调用 + 并发数匹配这四者闭环。漏掉任意一环，限流就只是配置文件里的一行静态文字。
