@retryable和retryoptions仅处理消息消费异常，不感知tcp连接断开；连接恢复必须依赖amqp-client的automaticrecoveryenabled，nestjs未暴露该配置开关。
nestjs 自带的 rabbitmq 策略不处理连接层断开，只管消费失败重试；连接断开必须靠底层 amqp-client 的 automaticrecoveryenabled，nestjs 本身不暴露该开关。
为什么 @Retryable 和 RetryOptions 对连接断开完全无效
NestJS 的 @Retryable 装饰器、RetryOptions 接口、以及 createRetryStrategy() 方法，全部作用于「消息消费逻辑抛异常」这一场景——即 Channel 已建立、消息已投递、但 handler 函数执行出错时的重入队/延迟重试。一旦 TCP 连接中断、Broker 不可达、或 connection.createChannel() 失败，这些机制根本不会触发。
常见错误现象包括：ERR_CONNECTION_REFUSED、Socket closed abruptly、Operation timed out，此时 NestJS 日志里看不到任何重试日志，服务直接卡死或报错退出。
-
@Retryable只捕获 handler 内部 throw 的异常，不感知连接状态 -
RetryOptions.retryAttempts控制的是「单条消息最多再试几次」，不是「连不上 Broker 时重试几次」 - 底层 amqp-client 默认关闭自动恢复（4.0.0+ 版本才默认开启，但 NestJS 封装层未透出控制权）
真正起作用的是 amqp-client 的 AutomaticRecoveryEnabled
NestJS 的 @nestjs/bull 或 @golevelup/nestjs-rabbitmq（官方 @nestjs/microservices 的 RabbitMQ 传输层）都基于 amqp-client。连接自愈能力必须在 ConnectionFactory 初始化阶段启用，且需调优关键参数：
- 必须显式设置
AutomaticRecoveryEnabled = true，不能依赖版本默认值（尤其老项目） -
NetworkRecoveryInterval建议设为5000（5 秒），太短会引发服务端连接风暴，太长导致恢复延迟过高 - 务必启用
TopologyRecoveryEnabled = true，否则重连后队列/交换器绑定丢失，消费者收不到新消息 - 避免设置
ConnectionTimeout过小（如1000），否则网络抖动时频繁触发假断连
如果你用的是 @golevelup/nestjs-rabbitmq，需在 RabbitMQModule.forRoot() 的 connection 配置中传入 raw options：
使用 JSON Schema 验证 JSON 数据，从示例 JSON 生成 schema，并将其转换为 TypeScript 接口、Python 数据类或 Markdown 文档。
{
connection: {
hostname: 'localhost',
port: 5672,
username: 'guest',
password: 'guest',
// ⚠️ 这些才是连接自愈的关键
connectionInitOptions: { wait: false },
connectionOptions: {
automaticRecovery: true,
networkRecoveryInterval: 5000,
topologyRecovery: true,
}
}
}
如何验证恢复是否生效
光配对没用，得确认底层连接真在重试。最直接的方式是监听 amqp-client 的恢复事件：
- 启动后手动停掉 RabbitMQ 容器（
docker stop rabbitmq） - 观察 NestJS 日志：应出现类似
Recovering connection...或Topology recovered的输出（取决于客户端版本） - 等 5 秒后重启 RabbitMQ，检查消费者是否自动重新注册并开始收消息（而不是一直 pending）
- 若日志只有
connect ECONNREFUSED且无后续恢复记录，说明automaticRecovery没生效或被覆盖
注意：NestJS 的 Logger 默认不打印 amqp-client 底层日志，必要时需 patch ConnectionFactory 或启用 DEBUG=amqp* 环境变量。
别把 consumer retry 和 connection recovery 混在一起调
这两个是完全正交的机制，配置位置、生效时机、失败原因都不同：
- Consumer retry（
spring.rabbitmq.listener.simple.retry.*那套）→ NestJS 里对应的是noAck: false+ 手动channel.nack(deliveryTag, false, true)，或使用@RabbitRPC/@RabbitSubscribe的重试装饰器 - Connection recovery（
AutomaticRecoveryEnabled）→ 必须在连接创建前设置，影响所有 channel 和 consumer 生命周期 - 混用时容易误判：比如把
retryAttempts: 3设很高，以为能扛住断连，结果连接一断就挂，因为压根没走到 retry 逻辑
真正复杂的地方在于：NestJS 没提供统一入口管理这两层重试，你得同时维护 transport 层配置和 handler 层策略，且它们的日志分散在不同模块里。
