可在@RabbitListener方法参数中直接声明MessageProperties，Spring AMQP自动注入；需手动ACK时须配置容器为MANUAL模式，并同时声明Channel和Message参数，用MessageProperties.getDeliveryTag()获取tag调用Channel方法。
在 @RabbitListener 方法里怎么拿到 MessageProperties？
直接通过方法参数声明 messageproperties 即可，spring amqp 会自动注入当前消息的元数据对象。它不是靠反射解析原始消息体得来的，而是从底层 channel 接收时就已封装好。
常见错误是试图从 Message 对象里手动调用 getMessageProperties()，但其实更简单：让 Spring 帮你传进来。
- 必须和实际消息体参数（如
String、byte[]、自定义 POJO）在同一方法签名中声明 - 顺序无关，Spring 按类型匹配，不是按位置
- 如果同时需要
Message和MessageProperties，两者可以共存，但通常只需后者——因为MessageProperties已包含messageId、correlationId、deliveryTag、headers等关键字段
@RabbitListener(queues = "my.queue")
public void handleMessage(String payload, MessageProperties properties) {
String msgId = properties.getMessageId();
Long deliveryTag = properties.getDeliveryTag(); // 注意：这是 long，不是 int
}@RabbitListener 能不能直接拿到 Channel？
不能直接声明 Channel 作为方法参数——Spring AMQP 不支持将 Channel 自动注入到监听方法中。这是有意设计的限制，因为 Channel 是有状态、非线程安全的资源，暴露给业务方法容易引发并发问题或误操作（比如手动 ack / nack 后忘记关闭）。
如果你确实需要 Channel（例如手动 ACK、拒绝消息、发回队列），正确做法是通过 ChannelAwareMessageListener 或利用 Channel 回调上下文。
- 最常用的是在方法参数中加
Channel+Message组合，但前提是开启容器级手动 ACK：acknowledge-mode="manual"（XML）或container.setAcknowledgeMode(AcknowledgeMode.MANUAL)（Java Config） - 此时 Spring 会把当前处理消息所用的
Channel注入进来，且保证它和当前消息生命周期一致 - 务必注意：一旦启用手动 ACK，就必须显式调用
channel.basicAck()或channel.basicNack()，否则消息会卡住、重复投递或堆积
@RabbitListener(queues = "my.queue")
public void handleMessage(String payload, Channel channel, Message message) throws IOException {
try {
// 处理业务逻辑
process(payload);
channel.basicAck(message.getMessageProperties().getDeliveryTag(), false);
} catch (Exception e) {
channel.basicNack(message.getMessageProperties().getDeliveryTag(), false, true);
}
}为什么有时候 MessageProperties.getDeliveryTag() 返回 null？
这通常是因为消息不是通过 RabbitMQ 原生投递路径进来的，比如：
- 测试时用
RabbitTemplate.convertAndSend()发送，但没走真实 broker（比如启用了spring.rabbitmq.dynamic=false或 mock connection） - 消息被其他中间件（如 Spring Cloud Stream Binder）二次封装，剥离了原始
MessageProperties - 使用了
SimpleMessageListenerContainer但未配置defaultRequeueRejected = false，导致某些异常场景下deliveryTag未正确写入
真正从 RabbitMQ 消费的消息，只要没被拦截或重构造，deliveryTag 一定不为 null——它是 broker 分配的唯一投递序号，用于 ACK/NACK。如果看到 null，优先检查是否绕过了真实 Channel 接收流程。
手动 ACK 场景下，Channel 和 MessageProperties 怎么配合用？
关键点在于：不要混用不同来源的 deliveryTag。必须用 MessageProperties.getDeliveryTag() 的值去调用 Channel.basicAck()，不能自己生成或硬编码。
-
MessageProperties.getDeliveryTag()返回的是long，而Channel.basicAck()第一个参数也是long，类型要对齐 - 第二个参数
multiple控制是否批量确认，一般设为false；第三个参数（basicNack专属）决定是否 requeue，别漏掉 - 如果监听器抛出未捕获异常，且容器配置了
defaultRequeueRejected=true（默认值），Spring 会自动帮你 nack 并 requeue——这时候你再手动调用basicNack()就会报错：java.io.IOException: PRECONDITION_FAILED - unknown delivery tag
所以，手动 ACK 的代码一定要包在 try-catch 里，并确保无论成功失败都只调用一次 ACK/NACK。多调用或漏调都会破坏消息可靠性。
