http handler 中不可裸调 ch.publish()，必然导致消息静默丢失或 amqp.error{code: 541} panic；根本原因是 handler 生命周期极短，响应写出后连接可能立即复用或关闭，此时 publish 仍在写已关闭 channel。
HTTP handler 里直接调 ch.Publish() 必然丢消息
不是“可能丢”，是大概率静默丢失，还伴随 amqp.Error{Code: 541} panic。根本原因是：Gin 的 HTTP handler 生命周期极短，w.WriteHeader() 或 w.Write() 一返回，底层 TCP 连接就可能被复用或关闭；此时 ch.Publish() 若还在写包，会撞上已关闭的 channel。
常见错误写法：
func handleOrder(c *gin.Context) {
data, _ := json.Marshal(Order{ID: "123"})
err := ch.Publish("", "order_queue", false, false, amqp.Publishing{Body: data})
if err != nil {
c.JSON(500, gin.H{"error": err.Error()})
return
}
c.JSON(200, gin.H{"ok": true})
}
这看似没问题，但只要网络稍抖、RabbitMQ 负载高一点，err 就是 amqp.ErrClosed 或直接 panic —— 而且你根本收不到日志，因为 goroutine 已随 handler 结束被回收。
- 必须把序列化 + 入缓冲 channel 作为 handler 唯一职责
- 缓冲 channel 类型推荐
chan []byte，容量设为 1000 左右（根据 QPS 调整） - 入 channel 时用
select { case msgCh ，绝不阻塞 - 真正 publish 逻辑必须在独立 goroutine 中执行，且每次调
ch.Publish()前检查ch.IsClosed()
ch.Consume() 绝不能放在任何 gin.HandlerFunc 里
它返回的是 ，for-range 会永久阻塞当前 goroutine —— 这个 goroutine 原本该毫秒级返回 HTTP 响应，结果变成一个卡死的消费者，后续所有请求排队挂起。
错误写法示例：
r.POST("/consume", func(c *gin.Context) {
msgs, _ := ch.Consume("email_queue", "", false, false, false, false, nil)
for msg := range msgs { // ← 这里就卡死了
processEmail(msg.Body)
msg.Ack(false)
}
})
正确做法只有一条：消费逻辑必须在 main() 启动阶段启动，与 Gin HTTP 服务并行运行。
- 每个消费者 goroutine 应绑定专属
*amqp.Channel，不共用 -
autoAck必须设为false，否则业务 panic 后消息直接消失 - 手动
msg.Ack(false)前，先做data := append([]byte(nil), msg.Body)拷贝 body，避免循环变量内存覆盖 - 失败时用
msg.Nack(false, true)（requeue=true），让消息回队头重试
连接和 channel 状态管理不是可选项，是保命线
RabbitMQ 连接随时可能因心跳超时、broker 重启、网络闪断而关闭。裸写的 for range msgs 或单次 ch.Publish() 一旦遇到断连，就永远停摆，整个链路静默中断。
必须监听两个关闭信号：
-
conn.NotifyClose()：连接断开，需重新amqp.Dial() -
ch.NotifyClose()：channel 断开，需在新连接上重建ch
重连不能立即重试，要带指数退避（如 1s → 2s → 4s → 8s），否则雪崩式重连会压垮 broker。
别信“全局单例 *amqp.Channel 复用”——channel 不可跨 goroutine 复用，也不可长期持有。每次断连后必须新建，且 ch.Confirm(false) 和 ch.NotifyPublish() 要在每次重建后重新注册。
amqp.Publishing 实例绝不能复用
很多人图省事定义一个全局 var pub amqp.Publishing，然后反复赋值 pub.Body = data 再发，这是高危操作。因为 amqp.Publishing 内部字段如 Headers map[string]interface{} 是引用类型，复用会导致多个消息共享同一 header，引发 PRECONDITION_FAILED - unknown delivery tag 错误，甚至消息被拒绝入队。
每次发送都必须新建实例：
err := ch.Publish("", queueName, false, false, amqp.Publishing{
ContentType: "application/json",
DeliveryMode: amqp.Persistent,
Body: data,
})
-
DeliveryMode: amqp.Persistent是硬性要求，否则 broker 重启消息全丢 -
ContentType必须显式设为"application/json"，否则消费者json.Unmarshal会静默失败 - 如果需要统一设置字段，封装成工厂函数：
newJSONPublishing(body []byte) amqp.Publishing
最易被忽略的一点：consumer 端收到消息后，msg.Ack(false) 很少真被执行——90% 场景下是业务逻辑里提前 return 或未捕获 panic 导致跳过。这不是代码漏写，是控制流没兜住。必须用 defer 包裹在处理函数最外层，且确保它绑定的是当前 msg 实例，而非循环变量。
