RabbitMQ 主动关闭 channel 的根本原因是客户端声明资源与服务端同名资源不兼容：404 表示队列/交换机不存在，需检查名称拼写、大小写及 vhost 配置；406 表示资源存在但参数冲突（如类型、持久化、死信配置等），应删除旧资源后重启应用重建，或统一各环境声明方式。
Shutdown Signal: channel error 不是随机断连，而是 RabbitMQ 主动关闭了 channel，根本原因是客户端声明的资源（队列/交换机/绑定）与服务端已存在的同名资源不兼容。
reply-code=404 表示资源根本不存在
典型日志：NOT_FOUND - no queue 'hello1' in vhost '/'。Spring Boot 启动时尝试声明一个队列，但 RabbitMQ 里压根没有这个队列。
- 检查
@Queue("boot_queue")名称是否拼写错误，或大小写不一致（RabbitMQ 队列名区分大小写） - 确认虚拟主机（vhost）配置是否匹配：
spring.rabbitmq.virtual-host必须和 Web 控制台里看到的一致，默认是/ - 如果用
RabbitAdmin手动声明资源，确保它已启用（未被注释掉），且connectionFactory已正确注入
reply-code=406 表示资源存在但参数冲突
典型日志：PRECONDITION_FAILED - inequivalent arg 'type' for exchange 'itcast.topic' 或 inequivalent arg 'x-dead-letter-exchange' for queue 'cancel-order-queue'。服务端已有同名资源，但类型、持久化、死信配置等关键参数不一致。
RabbitMQ 4.2.3
下载
RabbitMQ 4.2.3 是 2026 年初发布的重要稳定更新版本，重点修复了 Khepri 元数据存储相关问题，并改进了监控性能。对于使用 Docker、Kubernetes 或微服务架构的开发团队来说，该版本兼容性和稳定性表现较好。
- 最直接的办法是删掉 RabbitMQ Web 控制台里对应的老队列/交换机，再重启应用让它重建
- 不要试图“覆盖”——Spring AMQP 的声明逻辑是幂等的，但仅限于完全一致的参数；任何差异都会触发 406
- 开发阶段建议在
application.yml中加spring.rabbitmq.listener.simple.declare-exchanges=false，避免自动声明干扰调试
reply-code=406 还可能来自手动 ACK 配置错乱
日志里出现 unknown delivery tag 1，大概率是你开了手动确认（acknowledge-mode: manual），但代码里又漏调了 channel.basicAck() 或重复调用了它。
- 确认配置项写在对的位置：
spring.rabbitmq.listener.simple.acknowledge-mode=manual（不是direct下） - 消费者方法签名必须包含
Channel和Message参数，否则无法获取deliveryTag - 每个成功消费的消息，必须且只能调用一次
channel.basicAck()；失败时用basicNack(..., requeue=true)或basicReject()，别混用 - 切忌在 try-catch 外层吞掉异常却不做任何 ACK/NACK —— 这会导致 RabbitMQ 认为消息卡住，最终主动断开 channel
真正麻烦的不是报错本身，而是同一个队列在不同环境（dev/test/prod）里可能由不同方式创建：有的靠代码声明，有的靠运维脚本，有的靠控制台点出来的。只要有一处参数不一致，406 就会准时出现。上线前务必核对 RabbitMQ 管理界面里的实际定义，而不是只信代码注释。
