必须先关闭 channel 再关闭 connection，因为 channel 依赖 connection 存活；单独关 channel 不释放底层 tcp 连接，会导致连接泄漏；amqp 协议要求 channel 必须在 connection 关闭前显式终止，否则可能拒绝关闭或引发未定义行为。
为什么不能只关 Channel 就退出？
因为 amqp.Channel 依赖底层 amqp.Connection 存活；单独调用 ch.Close() 后，如果连接还开着，RabbitMQ 服务端仍会维持该连接的资源（如 TCP socket、内存句柄），长期积累会导致连接泄漏。Go 客户端不会自动帮你关掉父连接。
- Connection 是 TCP 级别连接，Channel 是 AMQP 协议层的轻量会话
- 一个 Connection 可以创建多个 Channel，但 Channel 关闭不影响 Connection
- 若程序 exit 前只关了 Channel 没关 Connection，
netstat -an | grep :5672会看到大量ESTABLISHED连接残留
关闭顺序必须是 Channel 先于 Connection
AMQP 协议要求：所有 Channel 必须在 Connection 关闭前显式终止，否则 RabbitMQ 可能拒绝关闭或产生未定义行为。Go 客户端库（streadway/amqp）在 conn.Close() 内部会尝试清理所有活跃 Channel，但不保证原子性——若仍有 Channel 在发消息或等响应，conn.Close() 可能阻塞或 panic。
- 正确顺序：
ch.Close()→conn.Close() - 错误顺序：
conn.Close()→ch.Close()（后者会 panic：invalid operation: use of closed network connection） - 建议加
defer时按反序写：defer conn.Close(); defer ch.Close()，确保执行时是正序
如何避免重复关闭导致 panic？
amqp.Connection.Close() 和 amqp.Channel.Close() 都不是幂等操作：重复调用会触发 panic，例如 panic: close of closed channel（注意这不是 channel，而是底层连接对象内部状态误判）。尤其在错误处理分支或信号中断逻辑中容易多路触发。
- 用指针 + nil 检查是最简单可靠的防护：
if ch != nil { ch.Close() } - 不要依赖
recover()捕获关闭 panic —— 这掩盖了逻辑错误，且无法保证资源释放成功 - 若封装成结构体方法，应在字段上加注释强调“Close 只能调用一次”，并在首次调用后置
ch = nil
优雅关闭还要处理正在消费的消息
单纯关 Channel 和 Connection 不足以实现“优雅”：如果 ch.Consume() 正在接收 Delivery，而你直接 ch.Close()，RabbitMQ 会把未 ack 的消息重新入队（取决于 auto-ack 设置），但你的程序已退出，消息可能被其他消费者重复处理。
- 必须先停投递：调用
ch.Cancel(consumerName, false)主动取消消费者，让服务端停止推送新消息 - 再等当前 handler goroutine 完成：用
sync.WaitGroup计数所有活跃的delivery.Ack()处理逻辑 - 最后才
ch.Close()→conn.Close()，顺序不能乱 - 忽略
ch.Cancel()直接关 Channel，可能导致 delivery 通道被强行切断，delivery.Ack()调用失败并 panic
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
