amqp.connection线程安全可复用，amqp.channel非线程安全须按需创建并独占使用；因channel含独立状态机，跨goroutine共享会导致序列号错乱、缓冲区竞争及panic。
amqp.Connection 和 amqp.Channel 不是并发安全的
Go 的 streadway/amqp 客户端库中，*amqp.Connection 和 *amqp.Channel 两个类型**本身没有内置互斥保护**。它们只是对 AMQP 协议连接和通道的封装，底层依赖 TCP 连接和状态机，所有方法（如 Channel.Publish、Connection.Close、Channel.Consume）都假设调用是串行的。一旦多个 goroutine 同时调用同一个 Channel 的 Publish 或 Close，就可能触发：panic: send on closed channel、invalid memory address or nil pointer dereference，甚至静默丢消息。
为什么复用 Connection 却不能复用 Channel？
AMQP 协议规定：一个 Connection 可承载多个 Channel，但每个 Channel 是**独立的状态机**，内部维护自己的序列号、确认窗口、未确认消息队列等。并发写入同一 Channel 会导致：
- 序列号错乱 → ACK/NACK 错位 → 消息被重复投递或意外丢弃
- 内部缓冲区（如
sendBuf）被多 goroutine 同时写入 → 内存越界或数据覆盖 -
Channel被某个 goroutine 关闭后，其他 goroutine 仍尝试使用 →panic: invalid operation: channel is closed
所以“复用 Connection”是对的，但“复用 Channel”是错的——必须为每个**逻辑上下文**（如一个消费者循环、一个生产者批次）分配独立 Channel，或加锁串行化访问。
常见错误模式：全局单例 Channel 导致雪崩
很多项目为了省事，把 ch *amqp.Channel 声明为包级变量并反复复用，结果在高并发压测下迅速崩溃。典型表现：
RabbitMQ 4.2.3 是 2026 年初发布的重要稳定更新版本，重点修复了 Khepri 元数据存储相关问题，并改进了监控性能。对于使用 Docker、Kubernetes 或微服务架构的开发团队来说，该版本兼容性和稳定性表现较好。
- 日志里频繁出现
Exception (504) Reason: "CHANNEL_ERROR - expected 'channel.open' - RabbitMQ 管理界面显示大量
channels处于unconfirmed状态 - Go 服务内存持续上涨，pprof 显示大量 goroutine 卡在
amqp.(*Channel).send
根本原因不是 RabbitMQ 限流，而是客户端自己把协议状态搞乱了。AMQP 不是 HTTP，它要求每个 Channel 上的操作严格有序。
正确做法：按需创建 + 显式生命周期管理
不要试图“保护”一个全局 Channel，而应让每个使用点拥有自己的 Channel 实例，并确保它被及时释放：
- 生产者场景：每次批量发布前
conn.Channel()，发完立刻ch.Close() - 消费者场景：每个
ch.Consume()循环独占一个Channel，退出时关闭 - 避免在 defer 中关闭跨 goroutine 共享的
Channel（defer 在定义它的 goroutine 退出时才执行） - 若需高频复用，可封装
ChannelPool，但池内每个Channel仍需保证单 goroutine 使用
真正容易被忽略的是：即使你没显式调用 ch.Close()，只要 Connection 关闭，所有关联 Channel 会自动失效——但此时已发生的并发调用可能早已触发 panic。
