因为Go的http.Handler生命周期极短，响应写出后连接可能被复用或关闭，此时amqp.Publish若遇网络抖动、RabbitMQ拒绝连接或channel已关闭，会panic或静默丢消息，实为“扔完不管”而非真正异步。
不能在 Gin 的 Handler 里直接调用 amqp.Publish 发送消息——HTTP 连接可能已复用或关闭，一出错就 panic 或静默丢消息。
为什么 Gin handler 里不能直接 publish 到 RabbitMQ？
Go 的 HTTP handler 生命周期极短：一旦 w.WriteHeader() 或 w.Write() 返回，底层 net.Conn 就可能被 http.Server 复用或关闭。此时若 amqp.Channel.Publish 正在执行（比如网络抖动、RabbitMQ 拒绝连接、channel 已 close），会触发 panic: send on closed channel 或直接丢弃消息，且无任何可观测反馈。
这不是异步，是“扔完不管”。真实生产环境里，这种写法会在压测或网络波动时批量丢任务。
- 常见错误包括：
defer ch.Close()放在 handler 末尾，但 channel 实际已在响应写出后被回收 - 没检查
ch.IsClosed()，复用已关闭的 channel 导致 panic - 用全局单例
*amqp.Channel并发写入，AMQP 协议不允许多 goroutine 同时写同一 channel
怎么让消息发送不阻塞 Gin 接口响应？
核心原则：Gin handler 只做两件事——序列化 + 投递到带缓冲的 chan []byte；真正 AMQP 发送由独立 goroutine 完成，且必须自带重试和连接恢复逻辑。
- 声明全局带缓冲 channel：
var msgCh = make(chan []byte, 1000)（缓冲大小按峰值 QPS × 平均处理延迟预估） - handler 中只做非阻塞投递：
select { case msgCh - 单独 goroutine 消费：
go func() { for payload := range msgCh { publishToRabbitMQ(payload) } }() -
publishToRabbitMQ必须每次新建amqp.Publishing实例，避免 header/headers 复用污染 - 必须捕获
amqp.Error类型（如NOT_FOUND队列不存在），不能直接panic或忽略
消费者端手动 ACK 为什么总失败？
不是 RabbitMQ 不给 ACK，是你没发出去。最常见原因是业务逻辑里 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) } }()中 - 不要用
msg.Ack(true)（multiple=true），它会批量确认前面所有未 ack 消息，容易误确认 - 如果业务处理耗时长，需在处理前调用
msg.Reject(false)主动 nack 并 requeue，避免超时被 RabbitMQ 强制重回队列
连接和 channel 怎么管理才可靠？
AMQP 连接（*amqp.Connection）和 channel（*amqp.Channel）都不是线程安全的，也不能长期持有——网络闪断、RabbitMQ 重启、broker 流控都会导致它们失效。硬扛一个连接只会让问题更隐蔽。
- 不要全局单例
*amqp.Connection，应封装为带重连的连接池（哪怕只维护一个连接） - 每次 publish 前检查
ch.IsClosed()，若为 true 则调用conn.Channel()新建 channel - 使用
errgroup.WithContext启动 publisher goroutine，并监听 context.Done() 主动关闭 channel - 配置 RabbitMQ 时开启
publisher-confirms和mandatory，确保消息抵达 exchange 且能路由到 queue
最容易被忽略的是：消息体序列化后是否保留了完整上下文（比如用户 ID、traceID），以及 consumer 是否做了幂等校验。没有 traceID，出问题时连日志都串不起来；没有幂等，网络重传会让同一条订单扣两次库存。
