HTTP响应不能等待RabbitMQ发送完成，需将投递剥离至handler外；handler中仅做JSON序列化和非阻塞写入缓冲channel，避免ch.Publish()同步调用导致接口卡顿或超时。
http 响应不能等 rabbitmq 发送完成，必须把投递动作从 handler 中剥离出去。 否则网络抖动、连接重建、broker 拒绝连接都会让接口卡住几秒甚至超时，用户看到的就是 504 或长等待。
handler 里只做序列化 + 非阻塞写入缓冲 channel
核心是避免任何可能阻塞的操作出现在 c.Next() 返回前。RabbitMQ 的 ch.Publish() 是同步调用，必须隔离。
- 声明全局带缓冲 channel：
var msgCh = make(chan []byte, 1000)（缓冲大小按峰值 QPS × 平均处理延迟预估） - 在 Gin handler 中只做 JSON 序列化和 select 写入：
select { case msgCh - 严禁在 goroutine 中直接传入
*gin.Context，所有需要的数据（如orderID、userID）必须提前提取为值类型副本
独立 goroutine 消费 channel 并重试发送
真正发消息的逻辑必须运行在单独 goroutine 中，且自带连接恢复与幂等重试——RabbitMQ 官方 client 不提供开箱即用的可靠发送。
- 启动消费循环：
go func() { for payload := range msgCh { publishToRabbitMQ(payload) } }() -
publishToRabbitMQ必须每次新建amqp.Publishing实例，避免复用导致headers污染 - 必须捕获
amqp.Error类型错误（如NOT_FOUND），不能忽略或直接 panic；对临时错误（如CONNECTION_FORCED）要指数退避重试 - 启用
ch.Confirm(false)，监听ch.NotifyPublish()确保消息至少到达 Broker，失败后重发并记录本地状态
为什么 autoAck: false 和手动 Ack/Nack 是刚需
消费者端漏掉 msg.Ack(false) 是队列卡死最常见原因，不是 RabbitMQ 不给 ACK，是你根本没发出去。
RabbitMQ 4.2.3
下载
RabbitMQ 4.2.3 是 2026 年初发布的重要稳定更新版本，重点修复了 Khepri 元数据存储相关问题，并改进了监控性能。对于使用 Docker、Kubernetes 或微服务架构的开发团队来说，该版本兼容性和稳定性表现较好。
- 业务逻辑中一旦出现
return、panic或未 recover 的 error，msg.Ack(false)就不会执行 - RabbitMQ 看不到 ACK，消息一直锁在
unacked状态，积压触发流控（flow control），整个 channel 被 block，新消息进不来 - 必须把
msg.Ack(false)放在defer里，且defer前确保msg非 nil - 必须包一层
defer func() { if r := recover(); r != nil { msg.Nack(false, true) } }()
最容易被忽略的是：RabbitMQ 的“可靠”不是配置出来的，而是靠每一步手动控制实现的——从 QueueDeclare 的 durable: true、amqp.Publishing{DeliveryMode: amqp.Persistent}、ch.Confirm()，到消费者端的 autoAck: false 和显式 Ack/Nack，缺一不可。任何一个环节设错，都可能导致消息静默丢失或队列堵死。
