Echo handler中不可直调ch.Publish或ch.Consume，必须用缓冲channel解耦、全局复用带超时心跳的AMQP连接、显式设Persistent+mandatory、启用publisher confirm、consumer首行defer msg.Ack(false)并设QoS。
在 Echo 框架中直接调 ch.Publish 或 ch.Consume 就等于给服务埋定时炸弹——消息会静默丢失、goroutine 会永久挂起、连接耗尽后整个 API 层就卡死。真解耦必须靠消息队列，而 RabbitMQ 是当前 Go 微服务里最可控的选择。
为什么不能在 Echo handler 里直连 RabbitMQ
常见错误现象是：接口返回 200 OK，但日志里查不到发消息记录，下游也收不到；更糟的是服务重启后发现一堆事件积压没处理。
-
http.ResponseWriter一旦写出响应（w.WriteHeader或w.Write），底层连接可能被复用或关闭，此时再调ch.Publish极易 panic 或静默失败 - 在 handler 里调
amqp.Dial或conn.Channel()，每次请求都新建 TCP 连接，高并发下很快触发connect: cannot assign requested address - 在 handler 里调
ch.Consume()会返回一个阻塞 channel，导致该 goroutine 永久挂起，HTTP 连接无法释放，很快耗尽并发数 - DNS 解析失败时默认无限阻塞，不设
connect_timeout=5就等于卡死整个 goroutine
怎么安全地把消息从 Echo 送进 RabbitMQ
核心原则：handler 只做序列化和入队，发送交给独立 goroutine 统一管控。
- 定义一个带缓冲的 channel：
msgChan := make(chan []byte, 1000)，Echo handler 里只做msgChan <- payload - 启动一个长期运行的 goroutine 消费该 channel，封装
publishToRabbitMQ()函数，内含重试、连接重建、失败落库逻辑 -
amqp.Connection必须全局单例，用sync.Once初始化，连接字符串中必须含connect_timeout=5和heartbeat=30 - 每次发消息前确保：
queue.Declare(..., durable: true)+publishing.DeliveryMode = amqp.Persistent+mandatory: true
消费者怎么写才不丢消息、不重复消费
最容易踩的坑是 Ack 时机不对，或者压根没做幂等校验。
立即学习“go语言免费学习笔记（深入）”；
- consumer 启动时必须调
ch.Qos(1, 0, false)，否则 RabbitMQ 会批量推送消息，OOM 或崩溃时大量 unack 消息丢失 - consumer handler 开头第一行就写
defer msg.Ack(false)——不是等业务跑完再手动 Ack，panic 或 return 会跳过它 - 业务逻辑开头必须做幂等校验，比如用
redis.SetNX("event:order_created_123", "1", time.Hour) - 消息处理失败时用
msg.Nack(false, true)触发重试，或主动发到 DLX（死信交换机）并记录日志
订阅主题命名和连接重建必须带版本与退避
用裸名如 "order" 或 "user" 订阅，上线后一升级就炸：v2 版本结构加字段，老消费者 JSON 反序列化 panic；新服务误订旧队列，消费不该处理的消息。
- 订阅主题必须带领域前缀和版本号，例如
"order.v2.created"或"payment.v1.completed" - 监听
conn.NotifyClose()，触发后清空旧连接，用指数退避（1s → 2s → 4s）重建Connection - 每次消费前重新
conn.Channel()，用完立刻ch.Close()；复用 Channel 会导致 RabbitMQ 报channel error: too many channels
真正麻烦的从来不是发一条消息，而是连接重建失败后是否兜底、失败消息是否落库、幂等键是否覆盖所有业务路径、mandatory: true 是否漏设——漏掉任何一个，系统就在温水里煮着，直到某次发布后突然积压告警炸出来。
