406 PRECONDITION_FAILED 表示 RabbitMQ 拒绝修改已存在资源的契约，如队列/Exchange 类型、durable、DLX 等参数不一致，或手动 ack 使用无效 delivery tag，需核对管理后台与代码声明参数是否完全匹配。
406 PRECONDITION_FAILED 不是网络或权限问题，而是 RabbitMQ 在拒绝你“改已存在资源的契约”——队列、Exchange 或参数不一致时，它会直接断开 channel。
查清到底是哪个资源参数冲突
错误日志里一定带关键线索，比如：
-
PRECONDITION_FAILED - inequivalent arg 'type' for exchange 'XXX'→ Exchange 类型（direct/topic/fanout）不一致 -
PRECONDITION_FAILED - inequivalent arg 'durable' for queue 'YYY'→ 队列持久化开关（truevsfalse）对不上 -
PRECONDITION_FAILED - inequivalent arg 'x-dead-letter-exchange'→ 死信交换机配置被新增/删改，但旧队列没这参数 -
PRECONDITION_FAILED - unknown delivery tag 1→ 不是声明冲突，是手动 ack 时用了已被确认或已过期的 tag
先去 RabbitMQ 管理后台（http://localhost:15672）点开对应 Exchanges 或 Queues 标签页，核对目标资源的当前属性，再和你代码里 queueDeclare() 或 exchangeDeclare() 的参数逐项比对。
队列/Exchange 已存在，但代码参数变了怎么办
RabbitMQ 不允许运行时修改队列或 Exchange 的核心参数（类型、durable、autoDelete、arguments 结构等）。一旦声明过，就锁死了。
- 开发环境：直接在管理后台删掉旧的
queue或exchange，重启服务让代码重新声明即可 - 生产环境不能删：改用新名字（如
export.queue.v2），并确保所有生产者、消费者都切过去 - 生产环境也不许改名：用
rabbitmqctl set_policy命令动态绑定 DLX（死信交换机）到已有队列，绕过代码声明
注意：arguments 里的数值类型也要一致，比如 x-message-ttl 写成 "3000"（String）和 3000（Long）会被视为不等价。
手动 ack 场景下出现 PRECONDITION_FAILED
这类错误常伴随 unknown delivery tag，本质是业务逻辑误用了 deliveryTag：
RabbitMQ 4.2.3 是 2026 年初发布的重要稳定更新版本，重点修复了 Khepri 元数据存储相关问题，并改进了监控性能。对于使用 Docker、Kubernetes 或微服务架构的开发团队来说，该版本兼容性和稳定性表现较好。
- 同一个
deliveryTag被重复ack或nack多次 - 消息已被自动重发（比如消费者 crash 后 channel 关闭），原 tag 失效
- 用了异步处理但没把
deliveryTag正确传进回调，导致调用时 tag 已过期
检查你的 listener 是否设置了 AcknowledgeMode.MANUAL，且每次处理完只调一次 channel.basicAck()；避免在 try/catch 外层无条件 ack，也别在多线程里共享 channel 实例。
超时类 PRECONDITION_FAILED（如 consumer_timeout）
当消费逻辑耗时超过 RabbitMQ 默认的 30 分钟（1800000 ms），它会主动关闭 channel 并报错：
- 临时生效：进容器执行
rabbitmqctl eval 'application:set_env(rabbit, consumer_timeout, 72000000).' - 永久生效：改
rabbitmq.conf，加一行consumer_timeout = 72000000 - 更推荐的做法：拆分长任务、用异步子任务 + 状态回调，而不是硬扛超时
这个 timeout 是服务端控制的，客户端设置 basicQos 或调整 ack 模式无法绕过它。
真正麻烦的不是报错本身，而是它往往藏在重试循环里反复触发——比如一个队列参数不一致，会导致 Spring-AMQP 不停重建 channel，刷屏日志还掩盖了原始原因。所以第一反应永远是：盯住第一条 406 日志里的完整错误文本，别急着重启。
