Spring Boot 2.0+ 默认使用 DirectMessageListenerContainer，它轻量、低延迟、每条消息独立 ACK；SimpleMessageListenerContainer 更重但支持动态扩缩容与批量事务确认，适用于长耗时或负载波动场景。
直接说结论：Spring Boot 2.0+ 默认用 DirectMessageListenerContainer，它更轻量、低延迟、适合短任务；SimpleMessageListenerContainer 更重但支持动态扩缩容和事务批量确认，适合长耗时或负载波动大的场景。选错容器会导致消息堆积、线程饥饿、ACK 失败甚至连接泄漏。
为什么 DirectMessageListenerContainer 没有 txSize 且必须手动逐条 ACK
因为它的消费者直接运行在 RabbitMQ Java Client 的 consumer 线程上，不经过 Spring 自己的线程池中转。这意味着：没有“事务批次”的概念，每条消息都独立触发监听器方法，也必须独立调用 channel.basicAck() 或 basicNack()。一旦你写成批量 ACK（比如缓存 deliveryTag 后统一 ack），会立刻抛 java.lang.IllegalStateException: Channel is not open —— 因为那个 channel 实例只在当前回调生命周期内有效。
- 错误写法：
if (messages.size() > 10) { channel.basicAck(..., true); } - 正确写法：
channel.basicAck(message.getMessageProperties().getDeliveryTag(), false); - 配置项
spring.rabbitmq.listener.direct.acknowledge-mode=manual是强制的，设成auto会静默忽略并回退到none模式
SimpleMessageListenerContainer 的 concurrentConsumers 和 maxConcurrentConsumers 怎么联动
它用固定线程池管理所有消费者，concurrentConsumers 是初始线程数，maxConcurrentConsumers 是上限。扩容/缩容靠四个隐式参数控制，默认值容易踩坑：
RabbitMQ 4.2.3 是 2026 年初发布的重要稳定更新版本，重点修复了 Khepri 元数据存储相关问题，并改进了监控性能。对于使用 Docker、Kubernetes 或微服务架构的开发团队来说，该版本兼容性和稳定性表现较好。
- 扩容条件：已有消费者连续 10 次检测周期（默认每秒一次）都收到至少一条消息，且距上次扩容已过 10 秒 → 才加一个消费者
- 缩容条件：某个消费者连续 10 次检测周期没收到消息（空闲），且距上次缩容已过 60 秒 → 才减一个消费者
- 关键陷阱：
receiveTimeout和txSize共同决定“空闲”判断：若txSize=5、receiveTimeout=1000，则空闲阈值是 5 秒（5 × 1000ms），不是 10 秒 - 实际效果：高并发突增时扩容滞后；低峰期缩容缓慢，线程长期闲置却不释放
DirectMessageListenerContainer 的 consumersPerQueue 为什么不能动态调整
它为每个队列单独创建消费者实例，每个消费者绑定一个独立线程，不共享线程池。所以 consumersPerQueue 是硬编码值，改了要重启容器才生效。这点和 Simple 的弹性模型完全不同：
- 优点：消息分发更公平，预取（
prefetchCount）默认为 1，避免单个慢消费者拖垮整队列 - 缺点：无法应对突发流量——比如某队列突然涌入 10 倍消息，只能靠增加该队列的
consumersPerQueue并重启应用 - 注意：
spring.rabbitmq.listener.direct.consumers-per-queue是每个队列的消费者数，不是全局总数；如果你监听 3 个队列且设为 2，实际会起 6 个消费者线程 - 线程名特征明显：
SimpleMessageListenerContainer-1vsDirectMessageListenerContainer-1，便于排查线程泄漏
什么时候必须换容器，而不是只调参数
光调 prefetch 或 concurrentConsumers 解决不了根本矛盾：
- 要严格保序且单队列处理能力恒定 → 用
DirectMessageListenerContainer+consumersPerQueue=1 - 消费逻辑平均耗时 > 500ms，且流量波峰波谷明显 → 必须用
SimpleMessageListenerContainer，否则Direct的固定线程会堵死 - 启用了
globalQos=true或需要跨消息做事务（如 JPA + RabbitMQ 同步 commit）→ 只能用Simple，因为Direct不支持txSize和批量 ACK - 出现
java.io.IOException: Connection reset by peer且伴随大量未确认消息 → 很可能是Direct容器里监听器阻塞了 RabbitMQ client 线程，此时必须切回Simple或把耗时操作扔进异步线程池
最常被忽略的一点：两个容器的 errorHandler 行为不同。Direct 抛异常后会立即关闭该消费者线程并重建，而 Simple 默认重试 3 次再丢弃；不显式配置 setErrorHandler，线上可能收不到任何错误告警。
