不能在 Gin handler 中直接调用 channel.Publish()，因 HTTP 连接可能已复用或关闭导致 541 错误、消息丢失、goroutine 卡死；应使用带缓冲 channel + 独立 goroutine 中转，每次新建 amqp.Publishing 实例并设 DeliveryMode 持久化。
不能在 Gin 的 HTTP handler 里直接调用 channel.Publish() 发送 RabbitMQ 消息——这不是异步，是埋雷。
为什么 channel.Publish() 不能写在 Gin handler 里
HTTP handler 生命周期极短：一旦 w.WriteHeader() 或 w.Write() 返回，底层连接可能立刻被复用或关闭。此时若 channel.Publish() 正在发包，会触发 amqp.Error{Code: 541}（channel closed），或静默丢消息。
- Go 的
http.Server默认启用连接复用（keep-alive），handler 执行完不等于连接还活着 -
channel不是线程安全的，多个请求并发调用同一channel实例，deliveryTag冲突导致PRECONDITION_FAILED - 网络抖动、RabbitMQ 拒绝连接、队列不存在（
NOT_FOUND）等错误未捕获，直接panic或忽略 - 没有 context 控制，超时/取消信号无法传播，goroutine 卡死无感知
正确做法：用带缓冲 channel + 独立 goroutine 中转
把「序列化消息」和「AMQP 发送」彻底解耦。Gin handler 只负责塞数据，发送由后台 goroutine 持续消费。
- 定义全局带缓冲 channel：
var publishCh = make(chan []byte, 1000)（缓冲大小按峰值 QPS × 平均处理耗时预估） - Gin handler 中只做：
publishCh <- json.Marshal(payload)，不碰任何 AMQP 对象 - 启动一个长期运行的 goroutine：
go func() { for b := range publishCh { sendToRabbitMQ(b) } }() -
sendToRabbitMQ()内部必须检查ch.IsClosed()，不可用则重建channel；每次调用都新建amqp.Publishing实例
amqp.Publishing 必须每次新建，不能复用
复用 amqp.Publishing 实例在并发场景下极其危险：其 Headers 是 map[string]interface{} 类型，底层共享内存，会导致消息头污染、字段覆盖，甚至触发 RabbitMQ 的 PRECONDITION_FAILED 错误。
- 封装工厂函数：
func newPublishing(body []byte) amqp.Publishing { return amqp.Publishing{DeliveryMode: amqp.Persistent, ContentType: "application/json", Body: body} } - 发送前务必设置
DeliveryMode: amqp.Persistent，否则 RabbitMQ 重启后消息丢失 - 不要设
Priority除非你启用了 queue 的x-max-priority参数，否则无效且增加序列化开销
连接与 channel 的生命周期管理要点
RabbitMQ 的 *amqp.Connection 和 *amqp.Channel 都不是“一劳永逸”的资源，必须主动监控和重建。
- 连接断开时，
conn.NotifyClose()会收到通知，此时需触发重连逻辑（不要用简单for {}重试，要加退避） - 每个
channel应绑定单一用途：一个专用于 publish，一个专用于 consume，禁止混用 - 不要在 goroutine 外层
defer ch.Close()—— 它会在 goroutine 启动时就执行，而非退出时 - consumer 启动时，
ch.Consume()第四个参数（autoAck）必须为false，否则消息一推送即删除，业务 panic 就永久丢失
真正难的不是写通第一行 ch.Publish()，而是让这套链路在高并发、网络抖动、RabbitMQ 重启、进程升级时都不丢消息、不 panic、不卡死——所有这些都藏在 channel 重建时机、publishing 实例生命周期、以及 context 传递的细节里。
