RabbitMQ因参数不一致主动关闭channel，错误码406提示如'x-max-priority'等声明参数与已存在队列/交换机定义冲突，需删除后用完全一致参数重建，并确保消息不丢失。
看 reply_code 和错误消息里的参数名
这个异常本质是 rabbitmq 主动关闭了 channel，不是客户端代码崩了。关键在括号里那串：(406, "precondition_failed - inequivalent arg 'x-max-priority' ...")。其中 406 表示服务端拒绝了你的声明请求，而引号内明确指出了冲突参数——比如 'x-max-priority'、'x-expires'、'durable' 或 'auto_delete'。
你不需要猜，直接提取错误消息中 inequivalent arg ' 后面那个带单引号的字符串，就是问题根源。它说明你这次 queue_declare() 或 exchange_declare() 传的参数，和队列/交换机当前已存在的定义不一致。
为什么参数会“不一致”？常见三类场景
参数冲突不是你写错了，而是 RabbitMQ 的强一致性策略导致的。只要队列或交换机已存在，后续声明必须完全匹配原有定义，否则报 406。
-
queue_declare(queue='scrape', arguments={'x-max-priority': 100})：但已有队列scrape是普通队列（没设x-max-priority），此时就会冲突 -
queue_declare(queue='source', arguments={'x-expires': 86400000})：但已有队列source没设置过x-expires，或者设的是别的值 -
exchange_declare(exchange='CLP_STG', durable=False)：但已有同名 exchange 是durable=True，也会触发406
快速修复：删旧建新，别硬改
RabbitMQ 不允许运行时修改队列/交换机的声明参数。想改，只能删掉重建。注意顺序和条件：
- 先检查 channel 是否还开着：
if channel.is_open:，避免在已关闭 channel 上调queue_delete()报ChannelWrongStateError - 用
channel.queue_delete(queue=QUEUE_NAME)删除旧队列（如果不确定是否存在，加if_exists=True更安全） - 再用完全一致的参数重新
queue_declare()，包括durable、exclusive、auto_delete和全部arguments - 如果是 exchange 冲突，同样用
channel.exchange_delete()+ 重声明，且exchange_type必须和原来一致
预防下次再踩坑：声明逻辑要幂等
生产环境不能靠手动删队列。你应该把声明逻辑写成“若存在且参数不匹配，则删+重建”，而不是无脑声明。尤其注意：
立即学习“Python免费学习笔记（深入）”；
- 所有
queue_declare()调用必须显式写出全部关键参数，不要依赖默认值——比如durable=False和不写durable在语义上不同 - 多个服务共用一个队列时，确保它们声明时用的
arguments完全一致，建议抽成常量统一管理 - 开发期可加一层 wrapper：捕获
pika.exceptions.ChannelClosedByBroker并判断e.reply_code == 406，自动执行删-建流程；但上线前务必确认该操作不影响正在消费的消息
真正麻烦的不是报错本身，而是队列里堆积的消息在删除时会丢失。所以删队列前，得确认它没有活跃消费者，或者消息已持久化且可重发。
