Consul中通过KV存储保存RabbitMQ的vhost、exchange、queue等纯字符串配置项，如mq/vhost→/order；channel作为运行时对象不可存储，仅可配置其依赖参数（如mq/heartbeat）；所有初始化与监听必须在Gin启动前完成，publish/consume须剥离HTTP链路、在独立goroutine中运行。
Consul 里怎么存 RabbitMQ 的 vhost 和 channel 配置
Consul 的 KV 存储只认字符串，不能直接存结构体或连接对象。vhost、exchange 名、queue 名、routing_key 这些都得作为纯字符串键值对写进去，比如：mq/vhost → /order，mq/exchange → order_exchange。信道（channel）本身不能“配置”，它是运行时对象，Consul 只能管它依赖的参数：比如 mq/max_reconnect_attempts 或 mq/heartbeat，这些会影响 channel 创建后的稳定性。
别把 amqp.Channel 实例塞进 Consul —— 它是 Go 运行时内存里的东西，序列化后毫无意义。真正该配的是连接串里的 vhost 段，以及后续声明 queue/exchange 时用到的名称、持久化标志等。
Gin 启动时从 Consul 加载并初始化 RabbitMQ 连接
必须在 main() 函数里、Gin router.Run() 之前完成 RabbitMQ 初始化，且要监听 Consul 的配置变更。常见错误是把 amqp.Dial() 放在某个 handler 里，或者只读一次配置就不再响应更新。
- 用
consulapi.NewClient()建连，调kv.Get()拉取mq/vhost、mq/url等键 -
amqp.Dial()的 URL 要拼上 vhost，例如"amqp://user:pass@127.0.0.1:5672" + vhostStr（注意 vhost 是 URL path，不是 query 参数） - 连接成功后，立刻用
conn.Channel()创建一个 channel，并缓存为全局变量（如var mqCh *amqp.Channel），供后续 publish/consume 复用 - 启动 goroutine 调
kv.Watch()监听 key 变更，一旦mq/vhost改了，要重建整个连接+channel 链路（不能只改 vhost）
为什么不能在 Gin handler 里调 ch.Publish() 或 ch.Consume()
这是最常踩的坑：ch.Publish() 在 handler 里裸调，大概率静默丢消息，还可能 panic amqp.Error{Code: 541}；ch.Consume() 放在 handler 里则直接卡死整个 HTTP 服务。
根本原因不是代码写错了，而是生命周期错配：
- handler 生命周期以毫秒计，
w.Write()返回后，底层 TCP 连接可能立刻被复用或关闭，此时ch.Publish()还在往已关闭 channel 写数据 -
ch.Consume()返回的是<-chan amqp.Delivery，for-range 会永久阻塞 goroutine —— 而这个 goroutine 是 Gin 启动的 HTTP worker，一卡住，所有新请求排队等它
正确做法只有一条：publish 和 consume 都必须剥离出 HTTP 请求链路，在 main() 启动阶段单独起 goroutine 运行。
channel 复用与隔离的边界在哪
一个 *amqp.Connection 可以开多个 *amqp.Channel，但每个 Channel 不是线程安全的 —— 不能跨 goroutine 并发调它的方法。实际项目中常见两种模式：
- 单 channel 全局复用：适合低并发、简单场景，但 publish 和 consume 逻辑必须串行协调，否则会互相干扰（比如 consumer 正在循环读，publish 突然写失败导致 channel 关闭）
- 按用途拆 channel：比如
pubCh专用于Publish()，subCh专用于Consume()，各自绑定独立 goroutine，互不抢占
无论哪种，都要在每次调 ch.Publish() 前检查 ch.IsClosed()，并在 goroutine 里做自动重连。不要指望 handler 里临时开 channel —— 开销大，且无法保证生命周期可控。
