http同步调用强耦合且易级联故障，rabbitmq通过异步解耦实现最终一致性，需全局连接、持久化消息、手动幂等ack及缓冲降级等完整设计。
HTTP 同步调用在微服务间直接穿透，不是“解耦”，是把网络故障、超时、重试逻辑全塞进业务代码里。RabbitMQ 替代 HTTP 的核心目的，是让服务之间彻底失去“此刻必须响应”的依赖——这要求从连接、消息生命周期、错误处理到消费者行为，全部按异步语义重新设计。
amqp.Connection 必须全局单例且带超时与重连
每次 amqp.Dial 都新建 TCP 连接，高并发下会快速耗尽本地端口（connect: cannot assign requested address），且 DNS 解析失败时默认无限阻塞。Connection 是重量级资源，不能随请求创建。
- 用
sync.Once初始化全局*amqp.Connection，URL 中必须含connect_timeout=5和heartbeat=30 - 监听
conn.NotifyClose，触发时清空旧连接并用指数退避重建（如 1s → 2s → 4s） - 禁止在 handler 或 goroutine 内直接
amqp.Dial，哪怕只调一次
发送消息前必须显式设置 durable + persistent + mandatory
默认直连 "" exchange、非持久队列、Transient 消息，等于把消息存在内存里——Broker 重启或断电，消息全丢。这不是“异步”，是“假装发了”。
RabbitMQ 4.2.3 是 2026 年初发布的重要稳定更新版本，重点修复了 Khepri 元数据存储相关问题，并改进了监控性能。对于使用 Docker、Kubernetes 或微服务架构的开发团队来说，该版本兼容性和稳定性表现较好。
- 声明队列时传
durable: true，否则DeliveryMode = amqp.Persistent无效 -
amqp.Publishing中必须设DeliveryMode: amqp.Persistent和mandatory: true -
mandatory: true让路由失败（如 exchange 不存在、binding 缺失）时立即返回 error，而非静默丢弃
消费者必须手动 Ack 且包裹在 defer 中
很多人写 msg.Ack(false) 放在业务逻辑中间，一旦前面 panic、return 或数据库报错，Ack 就被跳过。RabbitMQ 会一直 hold 住这条消息，最终积压、触发流控、拖垮整个 channel。
- 在 consumer handler 开头就
defer msg.Ack(false)，确保无论怎么退出都执行 - 业务逻辑必须幂等：消息可能重复投递（网络分区、Ack 超时未达 Broker）
- 若业务失败需重试，用
msg.Nack(requeue: true)并配合死信队列（DLX）+ TTL 控制重试次数
Gin/HTTP handler 内禁止直接调用 ch.Publish
HTTP 响应一旦写出（w.WriteHeader 或 w.Write），底层 connection 可能被复用或关闭。此时再发 RabbitMQ 消息，轻则 panic，重则消息丢失，且完全不可观测。
- handler 内只做序列化 + 写入带缓冲
chan []byte（如make(chan []byte, 1000)） - 独立 goroutine 持续消费该 channel，并在
publishToRabbitMQ()中封装重试、连接检查、ch.IsClosed()判断 - 缓冲满时降级策略要明确：写本地磁盘、打告警日志、或返回 503，绝不能阻塞 HTTP 请求
真正难的不是写通一条消息链路，而是让每个环节都接受“消息不一定立刻送达、不一定只送一次、不一定按顺序到达”这个事实。所有 retry、dlx、幂等、buffer fallback，都是为这个前提服务的——漏掉任意一环，异步就退化成不可靠的同步。
