NotifyClose只监听Channel关闭，不监听Connection断开；conn.NotifyClose()和ch.NotifyClose()必须分别注册，且通道需带缓冲（≥1）并配合select非阻塞接收，否则事件丢失或goroutine阻塞。
NotifyClose 本身不监听连接断开，只监听通道（Channel）关闭
很多人误以为 ch.NotifyClose() 能捕获连接断开，其实它只对 *amqp091.Channel 生效。连接断开（*amqp091.Connection 关闭）必须用 conn.NotifyClose() 单独注册——两者完全独立，漏掉任一个都会丢失关键事件。
常见错误现象：
网络闪断后程序没反应，日志里既没报错也没重连；查发现只监听了 channel 的 NotifyClose，而连接已静默关闭，后续 ch.Publish() 直接 panic："invalid memory address or nil pointer dereference"。
-
conn.NotifyClose()接收*amqp091.Error，表示连接级异常（如 TCP 断连、认证失败、心跳超时） -
ch.NotifyClose()同样接收*amqp091.Error，但仅表示该 channel 被服务器关闭（如 frame size 超限、权限不足、channel 拥塞） - 必须为每个活跃的
*amqp091.Channel单独调用NotifyClose()，复用 channel 变量不会自动继承通知逻辑
NotifyClose 通道容量必须设为 ≥1，且不能被阻塞
如果你传入 make(chan *amqp091.Error, 0)（无缓冲），又没在 goroutine 里立刻接收，那么第一次关闭事件就会永久阻塞，后续所有关闭通知都发不出——这会导致整个连接/通道状态监控彻底失效。
实操建议：
用带缓冲的通道，最小容量设为 1；配合 select + default 避免 goroutine 卡死；别把通知处理逻辑写成同步耗时操作。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 正确写法：
notify := ch.NotifyClose(make(chan *amqp091.Error, 1)) - 启动 goroutine 时加超时或非阻塞接收：
go func() { for { select { case err := <-notify: log.Printf("channel closed: %v", err) // 触发重连或清理 default: time.Sleep(100 * time.Millisecond) } } }() - 不要在
上直接阻塞主流程，尤其不要放在初始化函数末尾“等通知”
NotifyClose 不是重连保险丝，必须搭配主动健康检查
NotifyClose 是被动事件，依赖 AMQP 协议帧到达才触发。但真实网络中可能出现“连接已断、但服务器没发 close 帧”的情况（比如 NAT 超时、防火墙静默丢包），这时 NotifyClose 根本不会触发。
生产环境必须补主动探测：
定期调用 conn.IsClosed() 和 ch.IsClosed()，而不是只信 notify 通道。这两个方法是轻量级状态检查，不发网络请求，只读本地字段。
- 每 5–10 秒轮询一次连接和关键 channel 状态
- 一旦
conn.IsClosed() == true，立即停止使用所有从该 conn 创建的 channel，并启动重连流程 - 避免在重连函数里尝试
conn.Close()—— 如果 conn 已关闭，调用会 panic；应先判断!conn.IsClosed()再 close
HTTP API 监控比 NotifyClose 更可靠，但成本更高
AMQP 层的 NotifyClose 本质是协议帧反馈，受网络和 broker 实现影响大。RabbitMQ Management Plugin 提供的 HTTP 接口（如 /api/connections）能真实反映连接存活状态，且包含客户端 IP、端口、认证用户等上下文，更适合做告警依据。
权衡点：
HTTP 轮询有延迟（至少秒级）、增加 broker 负载、需开启 management_agent 插件；而 NotifyClose 是毫秒级响应，但不可靠。二者不是二选一，而是互补。
- 用
NotifyClose做快速响应（如立即停写、释放资源） - 用 HTTP API 做兜底验证（如连续 3 次轮询不到该连接，强制标记为 dead）
- 不要把
NotifyClose当作唯一故障信号——它只是你监控链条里的一环，不是终点
