amqp.Dial不能放进业务函数里，因为每次调用都会新建TCP连接，导致端口耗尽和资源浪费；正确做法是进程启动时全局单例复用Connection，并按需创建和关闭Channel。
amqp.Dial 为什么不能放进业务函数里
每次调用 amqp.Dial() 都会新建一个 TCP 连接，而 RabbitMQ 的 Connection 是重量级资源：单连接至少占 100KB 内存、需 7 个 TCP 包完成握手、服务端要长期维护状态。微服务常驻运行，若在 HTTP handler 或定时任务里反复 Dial，几小时内就会触发 connect: cannot assign requested address——系统端口耗尽，新连接直接失败。
常见错误模式包括：
- HTTP 接口里收到请求就
conn, _ := amqp.Dial(...)，处理完立刻conn.Close() - gRPC 方法里每次调用都新建连接
- 靠“首次调用懒加载”初始化连接，没做健康检查和重连兜底
本质是把短生命周期逻辑（一次请求）套用在长生命周期组件（RabbitMQ 连接）上，违背资源语义。
Connection 必须全局单例，不是连接池
RabbitMQ 协议本身不支持“连接复用”，所谓“连接池”其实是管理多个 *amqp.Connection 实例——但对绝大多数 Go 微服务来说，**一个全局复用的 Connection 就够了**，加连接池反而引入额外复杂度和状态同步风险。
立即学习“go语言免费学习笔记（深入）”；
正确做法是进程启动时一次性初始化 *amqp.Connection，全程复用。必须配齐三项关键配置：
-
Heartbeat: 10 * time.Second：K8s 网络策略或云厂商 LB 默认 30 秒空闲断连，RabbitMQ 默认心跳也是 30 秒，不显式设小一点，连接会静默断开 -
ConnectTimeout: 5 * time.Second：DNS 解析卡住或网络抖动时，避免 goroutine 永久阻塞 - 用
sync.Once或 DI 容器封装初始化逻辑，确保只执行一次；别用init函数（测试难 mock）
示例片段：
var (
conn *amqp.Connection
once sync.Once
)
<p>func GetRabbitMQConn() (<em>amqp.Connection, error) {
once.Do(func() {
var err error
conn, err = amqp.Dial("amqp://user:pass@rabbitmq:5672/", amqp.Config{
Heartbeat: 10 </em> time.Second,
ConnectTimeout: 5 * time.Second,
})
})
if conn == nil || conn.IsClosed() {
return nil, errors.New("rabbitmq connection unavailable")
}
return conn, nil
}Channel 必须按需创建并立刻 Close
别被“复用”二字误导：conn.Channel() 返回的 *amqp.Channel 不是线程安全的，也不能跨 goroutine 复用。每个消费者 goroutine、每个发布操作，都应独立调用 ch, _ := conn.Channel()，用完立刻 ch.Close()。
不 Close 的后果很直接：channel error: too many channels，RabbitMQ 主动关闭连接。
典型使用场景：
- HTTP handler 发消息：获取
ch→ch.Publish()→ch.Close() - 消费者 goroutine：获取
ch→ch.Consume()→ 在循环里处理消息 →msg.Ack()→ch.Close()（注意：不要在 Consume 后立刻 Close，要在消费循环结束时） - 定时任务发批量消息：每个消息单独建
ch，或复用一个ch但确保整个批次完成后 Close
真要搞连接池？优先用 amqp091-go + go-rabbitmq
自己手写 sync.Pool 管理 *amqp.Connection 极易出错：连接状态不同步、未处理 IsClosed()、重连逻辑缺失、未 ACK 消息丢失。实际项目中，除非有明确吞吐瓶颈（比如单连接打满 5k+ msg/s），否则没必要。
如果真需要连接池能力，优先用官方推荐的新 SDK：
- 库地址：
github.com/rabbitmq/amqp091-go+github.com/ThreeDotsLabs/go-rabbitmq - 它内置连接池雏形、自动重连、流控和 TCP 阻塞恢复，API 干净且适配 Go 1.21+ context 取消语义
-
streadway/amqp已归档，不再维护，新库修复了旧库 context 超时未传播、TLS 配置模糊等问题
迁移成本低：改 import、改函数名（如 amqp.Dial → amqp091.Dial），无逻辑变更。
真正容易被忽略的点是：Connection 复用 ≠ Channel 复用，更不等于“省事地全局存一个 ch”。Connection 是长寿命的基础设施，Channel 是短命的会话载体——前者管生命周期，后者管并发边界。漏掉任意一环，都会在压测或上线后突然崩掉。
