消费者无法直接从消息体读取死信来源，rabbitmq 不自动注入原始 exchange 和 routingkey；必须由生产者在发送时通过自定义 header（如 x-origin-exchange）显式传递，或采用按业务域隔离死信队列的方案。

消费者无法直接从消息体读取来源死信交换机

消息进入死信队列后，原始的 exchange 和 routingKey 信息不会自动写入消息体或 header。RabbitMQ 不会在转发死信时注入类似 x-origin-exchange 的元数据字段。你拿到的只是一条普通 AMQP 消息，message.getMessageProperties().getReceivedExchange() 返回的是**死信交换机的名字**（即 x-dead-letter-exchange 所指定的那个），不是它从哪个“上游交换机”来的。

必须靠约定 header 或自定义属性传递源头信息

要让消费端知道“这条死信最初来自 normal_exchange_v1 还是 refund_exchange”，得在生产者发消息时主动加标识。常见做法是：

• 生产者发送时，在 AMQP.BasicProperties 中手动设置自定义 header：headers.put("x-origin-exchange", "normal_exchange_v1")
• 如果使用 Spring AMQP，可在 MessagePostProcessor 中统一注入：message.getMessageProperties().setHeader("x-origin-exchange", exchangeName)
• 注意：这个 header 会随消息一起被死信机制透传到死信队列，消费端可用 message.getMessageProperties().getHeaders().get("x-origin-exchange") 安全读取
• 不要依赖 message.getMessageProperties().getReceivedRoutingKey() 判断来源——它返回的是死信路由 key（如 dead.order），不是原始路由 key

别误用 getReceivedExchange() 当作原始交换机名

这个方法返回的永远是当前投递所经的交换机，对死信队列里的消息来说，就是你配置的 x-dead-letter-exchange 名字。比如：

Java JDK 25

Java JDK 25 来自 OpenJDK 官方归档，版本为 JDK 25，本条下载地址已指向官方 Windows x64 zip 安装包直链，适合调试旧项目或兼容旧版 Java 运行环境。

下载

String receivedExchange = message.getMessageProperties().getReceivedExchange();
// 值为 "dlx.order"，不是 "order.exchange"

如果你没在生产者侧埋点，又没做交换机命名隔离（比如所有死信都走同一个 dlx.default），那消费端就真没法区分来源了。

真正可靠的方案是源头绑定 + 命名隔离

复杂业务中建议按场景拆分死信通道，而不是共用一套死信交换机/队列：

• 订单超时走 dlx.order → queue.dlx.order
• 支付失败走 dlx.payment → queue.dlx.payment
• 每个死信队列只接收一个业务域的死信，消费端通过监听的 queueName 就能反推来源
• 这样既避免 header 丢失风险，也降低消费逻辑分支判断成本

header 方案看似简单，但一旦某条消息漏埋、或中间有非 Java 客户端接入，就断链；而队列隔离是基础设施层的确定性保障。

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南