消费者一启动就退出，日志里有一长串：
PRECONDITION_FAILED - inequivalent arg 'x-...' for queue '...'这不是 RabbitMQ 连不上，而是已经存在一个同名队列，Magento 当前代码想用另一组属性再次声明它。RabbitMQ 会做属性等价检查，durable、exclusive、auto-delete 或 arguments 对不上时，直接关闭 channel，避免客户端悄悄改变现有队列语义。
先把错误原文保留下来
错误一般会同时写出“received”和“current”值，例如代码想要 x-queue-type=quorum，现有队列却是 classic。不要只截取第一行，因为具体哪个参数不同，决定了能否原地调整。
随后查看当前队列，而不是立刻删除：
rabbitmqctl list_queues -p / name durable auto_delete arguments messages_ready messages_unacknowledged consumers同时检查 Magento 模块中的 etc/queue_topology.xml、queue_consumer.xml，以及 RabbitMQ Policy。参数可能来自应用声明，也可能由 Policy 注入。只改一边，下一次部署仍会冲突。
我遇到最多的三个来源
- 升级模块后，开发者把已有 classic queue 改成 quorum，队列名字却没变；
- 两个 Magento 环境误用了同一个 vhost，测试环境用不同参数声明了生产队列；
- 旧模块已移除，但它创建的队列还在；新模块复用了同名队列。
有消息时，删除队列不是“修复”
如果 messages_ready 或 messages_unacknowledged 不为 0，删除会造成业务消息丢失或状态不一致。先确认消息对应什么业务：库存、异步操作、邮件与第三方同步的补偿方式完全不同。
生产上我更倾向于新建一个名字明确的新队列，让新代码发布到新队列；暂停旧生产者后把旧队列消费完，再下线旧绑定。若必须迁移消息，也要考虑消息是否仍适合新的队列类型、重试和死信设置，不能只把 payload 搬过去。
以 classic 改 quorum 为例，不能只改一个参数
队列类型变化通常意味着可用参数也跟着变。旧 classic queue 上的镜像参数、队列 TTL、优先级或独占设置，不一定能原样搬到 quorum queue。先根据当前 RabbitMQ 版本核对支持矩阵，再在测试 vhost 用与生产相同的 topology 声明一遍。
发布时还要考虑滚动部署：旧节点仍认为队列是 classic，新节点已经声明 quorum，两代代码同时在线就会互相打架。可以先发布兼容的生产者，让消息写到一个稳定 exchange，再切 binding 和 consumer；确认旧版本全部下线后，才移除旧队列。这样迁移边界在 RabbitMQ 拓扑，而不是寄希望于所有应用进程同一毫秒重启。
参数明明一样，为什么还报错
管理界面显示的名称相同，不代表来源相同。例如 x-dead-letter-exchange 可能由客户端 arguments 声明，也可能来自 policy；一个值是字符串，另一个被序列化成不同 AMQP 类型，也会不等价。把错误中的参数名、类型、received/current 原样对照 definitions，比肉眼看两份 XML 更可靠。
什么时候可以删除再重建
只有在确认队列没有待处理和未确认消息、没有旧版本节点仍在发布/消费，并且它可以从 Magento 配置安全重建时，我才会删除。操作前导出 definitions 或至少记录 exchange、binding、arguments，方便回滚和复盘。
修好后不要只看 consumer 进程“还活着”。发布一条可识别的测试消息，确认它只被处理一次，失败时进入预期的重试或死信路径；然后重启消费者，验证同名队列再次声明不会报错。能经得住重启，才说明参数来源已经统一。
