Connection.Blocked是RabbitMQ在内存或磁盘资源紧张时主动发送的AMQP流控信号，用于暂停生产者消息发送；它非错误而是保护机制，需通过conn.NotifyBlocked()监听并配合context超时、原子标志位等手段及时降级，否则将导致goroutine积压、TCP重传乃至连接被强制关闭。
Connection.Blocked 是什么，为什么必须响应
RabbitMQ 在内存或磁盘资源紧张时，会向客户端发送 Connection.Blocked 信号（AMQP 协议帧），强制暂停所有新消息的发送。这不是错误，而是流控机制的主动干预——此时 ch.Publish() 会阻塞，直到 RabbitMQ 解除阻塞或连接被断开。忽略它会导致 goroutine 积压、内存上涨、甚至触发 TCP 超时重传，最终连接被 RabbitMQ 主动 Connection.Close。
如何监听并响应 Connection.Blocked 事件
amqp091-go 提供了 conn.NotifyBlocked() 通道，用于接收阻塞/解除阻塞通知。必须在连接建立后立即注册，且该通道只接收 *amqp.Blocking 类型值（含 Reason 字段说明原因）：
- 监听需在
amqp.DialConfig()后、任何conn.Channel()前完成，否则可能错过首条Blocked -
conn.NotifyBlocked()返回的 channel 是单次消费设计，必须用for range持续读取，不能只select一次 -
Reason字段是纯文本（如"memory alarm"或"disk alarm"），不可用于结构化判断，仅作日志记录
blocked := conn.NotifyBlocked(make(chan *amqp.Blocking, 1))
go func() {
for b := range blocked {
if b == nil {
log.Println("RabbitMQ unblocked")
} else {
log.Printf("RabbitMQ blocked: %s", b.Reason)
// 此处可触发降级：暂停生产者 goroutine、切到本地缓冲、告警
}
}
}()
阻塞期间的生产者行为该怎么调整
收到 Connection.Blocked 后，ch.Publish() 会卡住，但你不能让业务逻辑等下去。正确做法是提前规避阻塞调用：
RabbitMQ 4.2.3
下载
RabbitMQ 4.2.3 是 2026 年初发布的重要稳定更新版本，重点修复了 Khepri 元数据存储相关问题，并改进了监控性能。对于使用 Docker、Kubernetes 或微服务架构的开发团队来说，该版本兼容性和稳定性表现较好。
- 所有
ch.Publish()必须加 context 控制超时（例如context.WithTimeout(ctx, 500*time.Millisecond)），避免无限等待 - 在 publish 前检查连接状态：
if conn.IsClosed() { ... }，但注意这无法捕获已阻塞未断连的状态 - 更可靠的方式是维护一个全局阻塞标志（
atomic.Bool），在NotifyBlocked的 handler 中原子更新，publish 前先读该标志 - 不要依赖
ch.IsClosed()判断——Channel 在阻塞期间仍是 open 状态，IsClosed()返回 false
为什么自动重连库（如 go-rabbitmq）也救不了这个场景
像 go-rabbitmq 这类封装库默认处理的是连接断开（Connection.Close），但 Connection.Blocked 不会关闭连接，只是挂起写入。这意味着：
- 重连逻辑完全不触发，库仍认为“连接健康”
- 若你把 publish 包在带重试的函数里，每次重试都会再次卡住，形成无效循环
- 真正需要的是“流控感知”，而非“连接恢复”——这必须由业务层主动配合，比如切换到内存队列暂存 + 定时轮询
blocked通道是否已解封
最易被忽略的一点：RabbitMQ 发送 Blocked 后，可能数秒内就发 Unblocked，但如果你的 publish 调用已在阻塞中，它不会自动恢复，必须靠超时中断后重新尝试。所以 context 超时不是备选方案，是必选项。
