必须用带缓冲channel+独立goroutine异步发送，因HTTP响应写出后连接可能回收，直调ch.Publish易panic或静默丢消息；需每次新建amqp.Publishing实例防header污染，且goroutine须支持context超时控制。
别在 HTTP handler 里直接调 ch.Publish 发邮件消息——连接可能已关闭，轻则 panic，重则消息静默丢失。必须用带缓冲 channel + 独立 goroutine 异步发送，且每次都要新建 amqp.Publishing 实例。
为什么不能在 Gin handler 里直发 RabbitMQ 消息
HTTP 响应一旦写出（w.WriteHeader 或 w.Write），底层连接就可能被复用或立即回收。此时若 ch.Publish 遇到网络抖动、队列不存在（amqp.Error{Code: 404}）、或 channel 已关闭，就会触发 panic 或丢消息。这不是异步，是“甩锅式发送”。
- 常见错误：裸起
go func() { ch.Publish(...) }()，没传context，超时/取消信号无法传递 - 更隐蔽的问题：
amqp.Publishing复用导致 header map 共享，多个消息互相污染，Broker 可能返回PRECONDITION_FAILED - unknown delivery tag - 连接未加
connect_timeout参数，DNS 慢或网络卡顿时，amqp.Dial会阻塞数秒甚至永久挂起
如何安全地把邮件事件丢进 RabbitMQ
核心思路：Gin handler 只做序列化 + 写入缓冲 channel；独立 goroutine 负责重试发送、状态检查和连接重建。
- 全局声明带缓冲的 channel：
var emailMsgCh = make(chan []byte, 1000) - Gin handler 中只做：
data, _ := json.Marshal(EmailEvent{To: "a@b.com", Subject: "Welcome"})，然后select { case emailMsgCh - 单独 goroutine 消费：
for payload := range emailMsgCh { err := publishEmail(payload) } -
publishEmail必须检查ch.IsClosed()，不可用时重建conn和ch；每次调用都新建amqp.Publishing{}，不复用变量
发送前必须设的三个持久化参数
直连空 exchange（""）看似简单，但默认配置下消息全在内存，Broker 重启即丢。生产环境必须显式控制：
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
立即学习“go语言免费学习笔记（深入）”；
-
DeliveryMode: amqp.Persistent—— 否则默认amqp.Transient，只存内存 - 队列声明时
durable: true—— 否则队列本身重启后消失，即使消息落盘也无效 - 发送时
mandatory: true—— 让 Broker 在路由失败时返回amqp.ErrPublish，而不是静默丢弃
注意：ch.Publish 返回 err ≠ 消息已投递成功，它只是把数据发出去了。真要可靠，得开 publisher confirm 模式 + ch.NotifyPublish 监听确认。
消费者端手动 ACK 容易漏掉的关键点
邮件消费者一写错，不是发不出去，而是反复重发——因为没 ACK，消息一直卡在 unacked 状态，积压后触发流控，最终堵死整个队列。
- 必须设
ch.Qos(1, 0, false)：限制预取数为 1，防止 Broker 一口气推几十封压垮服务 -
msg.Ack(false)必须放在业务逻辑**完全成功后**，且不能被return、panic或未捕获 error 跳过；推荐用defer msg.Ack(false)包裹，但要确保 defer 执行前没有提前 return - 消费逻辑里别用
log.Fatal或裸 panic，否则defer不执行，消息永远不确认
最常被忽略的是：消费者没设 durable: true 的队列声明，Broker 重启后队列没了，新消息直接被丢弃，而旧 unacked 消息也因队列消失无法恢复——表面看“没消息了”，其实是整个链路断了。
