我之前帮团队排查过一模一样的AMQP 1.0持久化订阅问题，结合RabbitMQ的AMQP 1.0适配逻辑，给你几个针对性的排查和解决方向：

1. 锁定订阅标识符（Subscription ID）的一致性 #

AMQP 1.0的持久化订阅完全依赖固定的订阅标识符关联历史消费状态。如果消费者B重启后生成了新的Subscription ID，RabbitMQ会直接判定为新订阅，不会恢复之前的持久化上下文。

• 必须确保消费者重启后使用完全相同的Subscription ID，绝对不能用随机生成的动态值；
• 对应到客户端代码里，要明确指定subscription-id参数（不同客户端API命名有差异，比如Java的Qpid JMS客户端用setSubscriptionName方法）。

2. 验证队列与绑定的持久化属性 #

别只盯着“持久化订阅”的设置，底层队列和绑定的持久化属性也不能忽略：

• 确认消费者创建订阅时，队列的durable属性被显式设为true；
• AMQP 1.0的绑定默认可能是非持久化的，要手动配置绑定的持久化标识；
• 可以通过RabbitMQ管理UI检查队列的Durable状态，以及绑定参数里的持久化配置。

3. 统一容器标识符（Container ID） #

RabbitMQ的AMQP 1.0适配器（基于Qpid Proton）通过容器标识符关联会话状态：

• 消费者重启后必须使用同一个Container ID重建连接，否则RabbitMQ找不到之前的会话记录；
• 别在代码里每次重启都生成新的Container ID，固定这个值就好；
• 检查客户端是否开启了会话自动恢复，部分AMQP 1.0客户端默认关闭该功能，比如Qpid JMS需要手动调用setAutomaticReconnect(true)。

4. 排查插件版本与日志 #

如果前面的配置都没问题，可能是插件本身的问题：

• 确保rabbitmq_amqp1_0插件是最新版本，旧版本确实存在持久化订阅恢复的Bug；
• 去RabbitMQ日志（比如/var/log/rabbitmq/rabbit@<hostname>.log）里搜AMQP 1.0、subscription关键词，看看有没有订阅状态加载失败的报错；
• 可以调整插件的amqp1_0.persistent_subscriptions_expiry配置，延长持久化订阅状态的保留时间，避免消费者下线过久导致状态被清理。

5. 用最小场景复现问题 #

如果还是卡壳，建议搭个简化场景测试：

• 写最精简的客户端代码（只做连接、持久化订阅、发消息）复现问题，排除第三方框架的干扰；
• 对比AMQP 0-9-1协议下的持久化订阅行为，确认是不是AMQP 1.0特有的适配问题。

补充一句：RabbitMQ对AMQP 1.0的支持是通过插件实现的，很多特性和原生AMQP 0-9-1有差异，持久化订阅的状态存储逻辑也不一样，必须严格遵循AMQP 1.0规范里的标识和会话恢复要求。

内容的提问来源于stack exchange，提问作者kumarb