Consumer 日志每隔几秒出现完全相同异常，队列深度不降。某条无法成功处理的毒消息如果无限 requeue，会占用 Worker、淹没日志并阻塞后续业务；直接删除又可能丢失订单或库存事件。
固定复现条件
记录 topic、脱敏消息 ID、redelivered 标志、首次与最后失败时间及异常指纹。区分暂时依赖故障、业务数据永久无效和代码缺陷。
php bin/magento queue:consumers:list
php bin/magento queue:consumers:start target.consumer --max-messages=5 -vvv
rabbitmqctl list_queues name messages_ready messages_unacknowledged consumers
rabbitmqctl list_bindings source_name destination_name routing_key
grep -RniE 'consumer|redeliver|reject|requeue' var/log | tail -n 100根据证据定位
网络超时适合有限退避重试；实体不存在或 schema 不兼容通常是永久失败；处理已完成但 ACK 前崩溃要求消费者幂等。所有错误都 requeue=true 会制造无限循环。
修复与回滚
为消息建立业务幂等键和明确重试预算，可恢复错误指数退避，永久错误进入死信或人工队列并保留脱敏证据。修复代码后按原消息语义安全重放，不要直接在 RabbitMQ 管理页批量 Purge。
验收
构造成功、暂时失败和永久失败消息；成功只产生一次副作用，暂时失败最终恢复，永久失败不再阻塞主队列且可追踪。
生产环境操作前的检查
处理“Magento 2 队列毒消息反复失败重试”前，先记录 Magento 版本、部署模式、问题 Store View、复现时间和最近发布。所有 SQL 默认先执行 SELECT；写操作、目录清理、服务重启和配置切换必须确认范围、保留备份并准备回滚。多节点环境还要核对构建版本、app/etc/env.php 配置摘要和实际流量节点。
php bin/magento --version
php bin/magento deploy:mode:show
php bin/magento maintenance:status
php bin/magento indexer:status
php bin/magento cache:status命令应由 Magento 文件所有者在项目根目录执行。不要在生产高峰同时运行全量索引、静态部署和数据修复；涉及客户、支付、税费、库存或订单的变更，应先在脱敏数据副本验证。
建立可比较的排查记录
每次实验只改变一个变量，记录操作前值、命令、开始与结束时间、结果和回滚方式。至少准备一个正常对象和一个异常对象；旧对象恢复而新对象仍能复现，说明根因尚未消除。
| 检查层 | 证据 | 通过标准 |
|---|---|---|
| 入口 | URL、状态码、请求 ID、节点 | 路由与协议一致 |
| 应用 | 异常堆栈、模块、作用域 | 无新异常且可重复 |
| 数据 | 主键、时间、关联行数 | 关系完整无重复副作用 |
| 业务 | 正常、失败与重试路径 | 最终状态一致 |
修复后的观察窗口
上线后至少观察一轮 Cron、队列和索引周期，并在两台节点、无痕浏览器与目标 Store View 重复验证。临时调试日志必须脱敏，确认错误率、响应时间和数据量稳定后及时关闭。
