真解耦必须用消息队列，rabbitmq是go微服务最可控选择；handler中禁止直连publish，须通过缓冲channel+独立goroutine统一处理重试、重建与落库；连接需全局单例、超时心跳、指数退避重建；消息必须持久化、队列durable、mandatory=true；消费者须defer ack、幂等校验、qos限流、超时控制。
真解耦必须用消息队列，RabbitMQ 是 Go 微服务里最可控、最容易落地的选择；HTTP/gRPC handler 里起 goroutine 直连 RabbitMQ 不算异步解耦，只是把同步调用藏进后台——下游一挂，协程堆积，消息静默丢失，服务照样雪崩。
为什么不能在 handler 里直接调 ch.Publish()
HTTP 响应一旦写出（w.WriteHeader 或 w.Write），底层连接可能被复用或关闭。此时再调 ch.Publish()，轻则 panic，重则消息无声丢失，且无日志可查。
- handler 只做两件事：序列化消息体、写入带缓冲的
chan []byte（比如make(chan []byte, 1000)） - 独立 goroutine 持续消费该 channel，并在封装函数
publishToRabbitMQ()中统一处理重试、连接重建、失败落库 - 绝对禁止在 Gin/Echo 的中间件或 handler 内调
amqp.Connection.Channel()或ch.Publish()
amqp.Dial() 必须全局单例 + 超时 + 心跳
每次 amqp.Dial() 都新建 TCP 连接，高并发下很快耗尽本地端口，报 connect: cannot assign requested address；DNS 解析失败时还默认无限阻塞。
- 用
sync.Once初始化全局*amqp.Connection - URL 中必须含
connect_timeout=5和heartbeat=30 - 监听
conn.NotifyClose，触发后清空旧连接，用指数退避（1s → 2s → 4s）重建 - Channel 按需创建、用完即
ch.Close()；泄漏会导致 RabbitMQ 报channel error: too many channels
发消息不设 DeliveryMode: amqp.Persistent 就等于没发
DeliveryMode: amqp.Transient（默认）意味着消息只存在内存，Broker 重启或断电就全丢——这不是异步，是“假装发了”。
- 声明队列时必须传
durable: true，否则DeliveryMode: amqp.Persistent无效 -
amqp.Publishing中必须设DeliveryMode: amqp.Persistent和mandatory: true -
mandatory: true让路由失败（如 exchange 不存在、binding 缺失）时立即返回 error，而不是静默丢弃
消费者不手动 defer msg.Ack(false) 就是给自己埋雷
RabbitMQ 的 consumer 不是“收到就干”，而是“收到→干活→显式 Ack→再收下一条”。很多人把 msg.Ack(false) 写在业务逻辑中间，一旦前面 panic、return 或 DB 报错，Ack 就被跳过——消息被 RabbitMQ 一直 hold 住，最终积压、触发流控、拖垮整个 channel。
- consumer handler 开头第一行就写
defer msg.Ack(false)，确保无论怎么退出都执行 - 必须先做幂等校验（比如用
redis.SetNX("processed:order_123", "1", time.Hour)），再执行业务逻辑 - 必须设
ch.Qos(1, 0, false)控制预取数，否则 RabbitMQ 会一口气推几百条给一个 consumer，OOM 或重启时全丢 - 用
context.WithTimeout包裹整个 handler，防止某条消息卡死整个 consumer
真正难的不是发消息，而是让每条消息都有迹可循、失败可重试、重复可识别、连接可自愈——这些细节不写进代码里，光靠“异步”两个字撑不了两天。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
