不能直接在Gin HTTP处理函数中阻塞发送RabbitMQ消息，因为handler同步执行，网络抖动或RabbitMQ临时不可用会导致请求卡住超时，QPS骤降；必须剥离投递逻辑至独立goroutine或worker池，仅保证“入队成功”而非等待ack，并通过带缓冲channel+固定worker数实现轻量可靠异步。
为什么不能直接在 Gin 的 HTTP 处理函数里阻塞发消息到 RabbitMQ
因为 channel.Publish() 虽然快，但网络抖动、RabbitMQ 临时不可用或未确认（confirm 模式开启时）会导致 HTTP 请求卡住甚至超时。Gin 的 handler 是同步执行的，一旦阻塞，整个请求响应就被拖住，QPS 直接掉——这不是异步，是假异步。
- 必须把消息投递逻辑剥离出 HTTP 生命周期，交给独立 goroutine 或 worker 池处理
- 若需投递结果反馈（比如“用户注册成功，邮件已入队”），应只保证“入队成功”，不等 RabbitMQ 的 ack
- 务必设置
amqp.Connection和amqp.Channel的超时与重试，否则 goroutine 泄漏风险极高
如何安全初始化 RabbitMQ 连接并复用 Channel
每次 HTTP 请求都新建 amqp.Connection 和 amqp.Channel 是反模式：连接开销大、易触发 RabbitMQ 的 connection limit，且 channel 不是线程安全的，多个 goroutine 并发写会 panic。
- 用单例 + sync.Once 初始化全局
*amqp.Connection，并在程序启动时建立 - 不要全局复用同一个
amqp.Channel；每个 goroutine 应调用conn.Channel()获取新 channel，用完立即channel.Close() - 务必监听
connection.NotifyClose()和channel.NotifyClose()，捕获异常后重建连接，否则静默失败
var conn *amqp.Connection
var connOnce sync.Once
<p>func getRabbitConn() *amqp.Connection {
connOnce.Do(func() {
var err error
conn, err = amqp.Dial("amqp://guest:guest@localhost:5672/")
if err != nil {
log.Fatal("RabbitMQ connect failed:", err)
}
})
return conn
}怎么让 Gin handler 把消息丢进队列而不阻塞
最轻量可靠的做法是用带缓冲的 channel 做中间队列，配合固定 worker 数量消费——避免无限制 goroutine 创建，也防止内存爆炸。
- 定义
type MQMessage struct { Exchange, RoutingKey, Body string }作为投递单元 - 启动时起 3–5 个常驻 goroutine，从
msgCh chan MQMessage消费并调用publishToRabbit() - Gin handler 中只做
msgCh ，只要缓冲区没满就立刻返回 - 缓冲区大小建议设为 100–1000，根据消息峰值和容忍丢失程度调整
消费者端如何避免消息重复或丢失
RabbitMQ 默认是“最多一次”（at-most-once），要达到“至少一次”（at-least-once），必须手动 ack，且 consumer 端不能 auto-ack。
立即学习“go语言免费学习笔记（深入）”；
- 创建 channel 时设
amqp.Qos(1, 0, false)控制预取数，防止 worker 积压太多未 ack 消息 - 消费时用
msgs, err := ch.Consume(..., false, ...)，第二个参数为false表示手动 ack - 业务逻辑成功后再调用
msg.Ack(false)；panic 或 error 时调用msg.Nack(false, true, false)让消息重回队首 - 注意：RabbitMQ 重启或 consumer 断连时，未 ack 消息会自动 requeue，这是机制保障，不是 bug
真正容易被忽略的是 connection recovery —— 大多数人只处理了 channel.Close，却没监听 conn.NotifyClose() 去重建整个连接链路。一旦网络闪断，后续所有 publish 都会 panic: "invalid connection state"。
