HTTP handler 中不可裸调 ch.Publish() 或 msg.Ack()，因 handler 生命周期极短，响应写出后连接可能立即复用或关闭，导致 amqp.Error{Code: 541}、panic 或消息静默丢失；必须剥离至独立 goroutine，配合 context 控制、ch.IsClosed() 检查、每次新建 Publishing 实例，并设 autoAck=false 手动确认。
HTTP handler 里直接调 ch.Publish() 或 msg.Ack()，消息大概率丢，还会 panic——这不是异步，是埋雷。
为什么 Gin handler 里不能裸调 RabbitMQ 方法
Go 的 HTTP handler 生命周期极短：响应一写出（w.WriteHeader() 或 w.Write()），连接就可能被复用或关闭。此时若 ch.Publish() 还在发包，会触发 amqp.Error{Code: 541}（channel closed）或静默失败。更危险的是，msg.Ack() 在 handler 里裸调，一旦业务逻辑 panic 或提前 return，ACK 就永远不执行，消息卡在 unacked 状态，队列很快积压、流控、甚至堵死。
- 现象：
amqp.Publishing发送成功日志有，但 RabbitMQ 管理后台看不到消息入队 - 根本原因：handler 返回后，
*amqp.Channel可能已关闭，但 publish 调用仍在尝试写底层 TCP 连接 - 别信“加个 goroutine 就行”——没 context 控制、没 channel 状态检查、没重试，只是把 panic 延后几毫秒
生产者：Gin 中怎么安全发消息
核心原则：只做序列化 + 入缓冲 channel；真正 publish 交给独立 goroutine，且每次发送都重建 amqp.Publishing 实例。
- 用带缓冲的全局
msgCh = make(chan []byte, 1000)，避免 handler 阻塞 - handler 内只做：
data, _ := json.Marshal(MyTask{ID: "123"})，然后select { case msgCh - 独立 goroutine 消费：
for payload := range msgCh { publishToRabbitMQ(payload) }，其中publishToRabbitMQ必须包含：- 检查
ch.IsClosed()，关闭则重建 channel - 每次调
ch.Publish()前新建amqp.Publishing，绝不复用（尤其Headers map[string]interface{}是引用，复用会污染） - 设
DeliveryMode: amqp.Persistent，否则 broker 重启消息全丢 - 开启
ch.Confirm(false)并监听ch.NotifyPublish()，捕获 broker 是否真正接收
- 检查
消费者：手动 ACK 为什么总漏掉
不是忘了写 msg.Ack(false)，而是写了却没被执行——90% 的漏 ACK 来自业务逻辑里的 return、panic 或未捕获 error。
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
立即学习“go语言免费学习笔记（深入）”；
- 错误写法：
if err := process(msg.Body); err != nil { log.Printf("fail: %v", err); return } msg.Ack(false)→return后 ACK 永远不执行 - 正确写法：用
defer但必须绑定当前 msg，且确保 msg 不是循环变量：go func(d amqp.Delivery) { defer d.Ack(false); process(d.Body) }(msg) - 必须传
autoAck: false给ch.Consume()，第四个参数是它：ch.Consume("q", "", false, false, false, false, nil) -
deliveryTag是 per-channel 单调递增整数，跨 goroutine 确认会报PRECONDITION_FAILED - unknown delivery tag，所以msg.Ack()必须在消费它的同一个ch上调用
连接与 channel 生命周期怎么管
连接必须单例，channel 不能复用，但也不能每条消息都新建——得在“复用”和“安全”之间卡准节奏。
-
amqp.Dial()全局一次，带心跳：amqp.Config{Heartbeat: 10 * time.Second}，否则 K8s LB 30 秒空闲断连 - URL 中 vhost 必须 URL 编码：
"amqp://user:pass@localhost:5672/%2F"，写成/或空字符串直接ACCESS_REFUSED - channel 按业务域隔离（如“订单事件 channel” vs “日志上报 channel”），别所有消息共用一个
- 监听
conn.NotifyClose()，触发自动重连逻辑；ch.Publish()失败时先查ch.IsClosed()，再决定是重建 channel 还是重试 - QueueDeclare 必须
durable: true且autoDelete: false，否则服务重启队列消失，新消息无处可存
最易被忽略的点：deliveryTag 不是全局唯一 ID，它只在当前 channel 内有效；consumer goroutine 共享 channel 时，并发调 msg.Ack() 会因 deliveryTag 冲突直接失败——要么单 channel 单 goroutine，要么加锁，别图省事。
