线上服务 goroutine 数持续上涨、内存缓慢增长、RabbitMQ 消费延迟升高，八成是 amqp.Channel 复用不当 + 协程未退出导致的泄漏；根本原因是 channel 生命周期与 goroutine 退出路径未对齐，如 NotifyClose 通道未消费、Consume 后未 Cancel、Publish/Consume 混用等。
线上服务 goroutine 数持续上涨、内存缓慢增长、RabbitMQ 消费延迟升高，八成是 amqp.Channel 复用不当 + 协程未退出导致的泄漏。这不是配置问题，而是 channel 生命周期和 goroutine 退出路径没对齐。
为什么复用 amqp.Channel 容易引发协程泄露
RabbitMQ 的 amqp.Channel 本身不是 goroutine 安全的，但更危险的是：它内部会启动多个后台 goroutine（比如 readLoop、writeLoop），这些 goroutine 的生命周期绑定在 channel 实例上 —— 只要 channel 没被 Close()，它们就一直活着。
常见误用模式：
- 把一个
*amqp.Channel在多个 goroutine 中并发调用Publish()或Consume()，没加锁也没隔离，导致底层连接状态错乱，触发重连逻辑，悄悄启新 goroutine - 用完 channel 后只
defer ch.Close()，但该 defer 所在函数早已返回，channel 实际没关（比如在 HTTP handler 里 defer，但 handler 返回后 goroutine 还在等消息） - channel 关闭后，仍有 goroutine 在监听其
NotifyClose()或NotifyCancel()通道，而这些通知通道未被消费，造成接收方永久阻塞
amqp.Channel.NotifyClose() 不消费就会卡死 goroutine
这是最隐蔽的泄漏点。一旦你调用了 ch.NotifyClose(chClosed)，RabbitMQ 客户端就会为这个 channel 启一个专属 goroutine，负责向 chClosed 发送关闭事件。但如果你从不读这个 channel，它就会永远阻塞在发送侧 —— 因为 NotifyClose 内部用的是无缓冲 channel。
立即学习“go语言免费学习笔记（深入）”；
实操建议：
- 只在需要响应 channel 关闭事件时才调用
NotifyClose()，且必须确保有 goroutine 持续接收chClosed - 若只是想“监听异常”，改用
conn.NotifyClose()更安全（连接级，粒度粗但不易漏） - 测试时用
goleak.VerifyNone(t)能直接捕获这类泄漏：一个未读的NotifyClose通道，会留下至少 2 个常驻 goroutine
Channel 复用的正确姿势：按场景隔离，不共享
Go 的 amqp.Channel 不是“越复用越好”。它的复用边界必须和业务语义一致：
- 发布（Publish）场景：每个独立业务流（如订单、日志、告警）应使用独立 channel，避免某条流失败影响其他流；复用同一 channel 发布不同优先级消息，可能因 TCP 缓冲区挤占导致高优消息延迟
- 消费（Consume）场景：每个
ch.Consume()调用应配一个 dedicated goroutine 处理其msgschannel，并在 consumer 退出时显式ch.Cancel()—— 注意，Cancel()不等于Close()，它只停消费，channel 还能发 - 绝对禁止：把一个 channel 同时用于
Consume()和Publish()，AMQP 协议不保证这种混用的稳定性，客户端底层可能 panic 或静默丢消息
性能提示：amqp.Connection 才是重量级资源，channel 是轻量级，创建/销毁 channel 开销极小（毫秒级），别为了省 channel 而牺牲可维护性。
线上快速定位泄漏点的三步法
别等 OOM。只要发现 runtime.NumGoroutine() 单日上涨超 10%，立刻执行：
- curl
http://localhost:6060/debug/pprof/goroutine?debug=2，搜索关键词：readLoop、writeLoop、NotifyClose、Consume—— 出现上百次同名堆栈，基本锁定泄漏 channel - 检查所有
amqp.Dial()调用点，确认是否都配了defer conn.Close()；再查所有conn.Channel()，确认每个返回的ch是否都有明确的ch.Close()或ch.Cancel()路径 - 重点 audit 所有带
go func() { ... }()的 RabbitMQ 相关代码，看是否遗漏了select的default或ctx.Done()分支，导致 goroutine 卡在msgs接收上
最易被忽略的是：消费 goroutine 里处理业务逻辑时发生 panic，没 recover，导致 ch.Cancel() 和 ch.Close() 永远不执行 —— 这类泄漏不会立刻暴露，但压测时会集中爆发。
