AMQP信道关闭后不可复用，必须重建并重设QoS、队列声明和Notify回调；ch.Publish()会panic因底层信道已进入协议层终态，需通过ch.NotifyClose监听并手动恢复。
“Channel closed” 不是偶发错误，而是 AMQP 协议层的正常状态反馈 —— 信道一旦关闭就不可复用，必须显式重建。官方 amqp091-go 库不提供自动重建逻辑，所有重试、恢复、状态同步都得你手动写。
为什么 ch.Close() 后再调 ch.Publish() 会 panic？
AMQP 信道（*amqp.Channel）是单次生命周期对象：一旦收到服务端 channel.close 帧（比如队列被删、权限变更、broker 重启），底层连接会标记该 channel 为 closed 状态，后续任何方法调用（包括 Publish、Consume、Qos）都会直接 panic，错误信息类似 send on closed channel 或 invalid operation: channel is closed。
- 这不是 Go 的 channel 关闭，而是 AMQP 协议定义的信道终态，无法 reset 或 reopen
- 即使你没主动调
ch.Close()，网络闪断、broker 重启、vhost 权限回收都会触发服务端单向关闭 - 官方库不会拦截或重试这些调用 —— 它把状态交还给你判断
如何安全检测并重建信道？
不能靠 defer 或 recover，得从连接层监听信道关闭事件，并在业务调用前确保信道可用。核心是两件事：监听 ch.NotifyClose()、封装带重试的 channel 获取逻辑。
- 每个
*amqp.Channel创建后立即调用ch.NotifyClose(make(chan *amqp.Error, 1))，这个通道会在信道关闭时收到一个非 nil 错误 - 不要在 goroutine 里长期持有单一
ch变量；应把 channel 封装成带状态的结构体，例如type SafeChannel struct { mu sync.RWMutex; ch *amqp.Channel } - 对外暴露
Get() (*amqp.Channel, error)方法：先读锁取 channel，若已关闭则加写锁重建（需重用原*amqp.Connection） - 重建时务必重新设置 QoS、Declare Queue、Bind Exchange —— 这些不是信道自带的，每次新建都要重做
重建时最容易漏掉的三件事
信道重建不是 conn.Channel() 一行完事，少做一步就会导致消息丢失或消费卡死。
-
ch.Qos(1, 0, false)必须重设：否则新信道默认无 prefetch 限制，大量消息涌入可能压垮消费者 -
ch.QueueDeclare(..., durable: true, ...)要显式声明：不能依赖 auto-delete 队列或“之前存在就跳过”的假设，broker 重启后队列状态不保证延续 -
ch.NotifyReturn()和ch.NotifyCancel()如果用了，也得在新信道上重新注册：旧 channel 上的 notify 通道已失效，不会收到新事件
要不要用 wagslane/go-rabbitmq 这类封装库？
它确实封装了信道重建、连接重试、context 取消传播，但代价是隐藏了底层控制权。如果你需要精细控制重试间隔、失败降级策略（比如切备用 exchange）、或和现有监控链路（如 OpenTelemetry）深度集成，自己封装更可控。
真正难的不是重建信道，而是重建后如何保证消息语义不乱：比如正在处理的 delivery 是否要补 Ack/Nack？重连期间未确认的消息会不会被 broker 重发两次？这些边界情况，库不会替你决策，得结合业务幂等设计来兜底。
