Fiber框架不管理RabbitMQ连接，关键在于连接全局单例、Channel按需创建并及时关闭、监听NotifyClose实现重连、队列与消息均需持久化、Consumer需绑定context并手动Ack。
直接说结论：Fiber 框架本身不参与 RabbitMQ 连接管理，对接的关键不是“怎么在 Fiber 里写 MQ 代码”，而是「连接复用 + 生命周期对齐 + Channel 隔离」——否则服务跑几天就断连、panic 或消息丢失。
amqp.Dial() 不能放在 HTTP handler 里反复调用
很多人一上来就在 app.Post("/send", func(c *fiber.Ctx) error { ... })
里写 amqp.Dial()，这是最典型的线上事故源头。每次请求新建连接，不出半天端口耗尽、RabbitMQ 主动踢人、connection closed 错误刷屏。
- 连接必须全局单例，在 Fiber 启动前初始化（比如
main()或app.Startup()阶段） - 务必传
amqp.Config{Heartbeat: 10 * time.Second}，否则 K8s Service 或云 LB 空闲 30 秒后静默断连 - 不要依赖
amqp.Dial("amqp://...")的默认心跳，显式声明更可靠 - 连接异常时需监听
conn.NotifyClose()并触发重连逻辑（如指数退避），Fiber 不会帮你做这事
Channel 必须按需创建、用完即关，别存成全局变量
*amqp.Channel 不是线程安全的，跨 goroutine 复用会直接 panic：invalid memory address or nil pointer dereference 或 send on closed channel。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 生产者场景：每个 HTTP 请求里调
conn.Channel()→ 发完消息立刻ch.Close() - 消费者场景：启动独立 goroutine，每次
ch.Consume()前新建ch，消费循环结束后ch.Close() - 别缓存
Channel到 struct 字段或 map 里——它比 Connection 轻量，但绝不共享 - Fiber 的并发模型基于 goroutine，你写的 handler 本身就是并发执行的，这点尤其容易踩坑
QueueDeclare 和 Publish 必须配对持久化参数
“消息没丢”不是默认行为，而是靠四个地方手动对齐：队列声明、交换机绑定、消息发布、消费确认。漏一个，重启后消息就消失。
-
ch.QueueDeclare("myq", true, false, false, false, nil)：第二个参数true是硬性要求，否则 RabbitMQ 重启后队列元数据丢失 -
ch.ExchangeDeclare("myex", "topic", true, false, false, false, nil)：交换机也要durable: true，否则绑定关系失效 -
ch.Publish(..., amqp.Publishing{DeliveryMode: amqp.Persistent, ...})：仅队列持久化不够，消息体也得落盘 - 别用
ch.PublishWithDeferredConfirm()就以为万事大吉——要真想确认送达，得配合ch.NotifyPublish()监听 broker ack/nack
Consumer goroutine 怎么和 Fiber 生命周期协同
Fiber 没有内置的后台任务生命周期钩子，consumer goroutine 容易变成孤儿进程，或者服务关闭时消息正在处理却被粗暴终止。
- 用
app.Server().RegisterOnShutdown()注册清理函数，在 shutdown 时通知 consumer 停止并等待当前消息处理完 - consumer 内部用
context.WithCancel()控制循环退出，别用无限for {} - 手动 ACK 前确保业务逻辑已提交（比如 DB 写入成功），再调
msg.Ack(false)；失败时用msg.Nack(false, true)回队重试 - 必须设
ch.Qos(1, 0, false)，否则一个 consumer 可能预取几百条消息，其他实例饿死，且崩溃时大量未 ACK 消息卡住
真正难的从来不是“怎么发一条消息”，而是连接不断、Channel 不炸、队列不丢、消息不卡、重启不漏——这些都得靠你在 Fiber 启动/关闭流程里亲手串起来，框架不会替你决定哪一步该阻塞、哪一步该超时、哪一步该重试。
