Beego集成RabbitMQ需手动引入streadway/amqp，避免裸调Dial、禁止Consumer绑定HTTP生命周期，须独立goroutine运行并显式ACK，日志必须携带msg.MessageId以保障可追踪性。
Beego 本身不提供消息队列抽象层，所谓“对接 RabbitMQ”本质是手动集成 streadway/amqp，并绕开 Beego 的 HTTP 生命周期约束——否则消费者 goroutine 会随请求结束被回收，ACK 永远发不出去，消息持续重复投递。
Beego 启动时不能裸调 amqp.Dial()
Beego 的 app.Run() 是阻塞调用，如果在 main() 或 init() 里直接 amqp.Dial()，一旦网络不通、认证失败或 DNS 未就绪，服务直接 panic 退出，而不是降级运行。
- 必须包装成带超时和重试的初始化函数，例如用
context.WithTimeout控制连接耗时 - 推荐用
sync.Once+time.AfterFunc延迟初始化：启动 HTTP 服务后 2 秒再尝试连 RabbitMQ - 连接失败时记录
warn日志，设置全局状态如rabbitmq.status = "unavailable"，绝不log.Fatal或panic - 连接字符串必须从配置读取：
beego.AppConfig.String("rabbitmq::url")，禁止硬编码
Consumer 必须脱离 Controller 独立长运行
常见错误是把 ch.Consume() 放进 Controller.Get() 里，然后 for range 消费——这会让消费者逻辑绑定在单次 HTTP 请求生命周期内，请求一结束，goroutine 被回收，msg.Ack() 永远不会执行。
- Consumer 必须作为独立 goroutine，在
beego.AppInit()阶段启动：go func() { ... }() - ACK/NACK 必须由该 goroutine 自己完成，不能跨 goroutine 调用 Controller 方法
- 若需回传处理结果（如更新订单状态），应走
sync.Map、本地chan或 Redis 缓存中转 - 不要在循环里反复
amqp.Dial()或conn.Channel()，复用初始化好的连接和 channel
msg.Ack() 和 msg.Nack() 的调用时机很关键
ACK 不是“处理完就发”，而是“确认能安全丢弃”。一旦 ACK，消息就从队列永久移除；NACK 则决定是否重入队尾。错用会导致消息丢失或无限重试。
- 成功处理后调用
msg.Ack(false)（false表示非批量） - 处理出错时，用
msg.Nack(false, true)让消息重回队尾（true表示 requeue） - 发生 panic 时，必须在
recover()后调用msg.Nack(false, false)（不重入），避免死循环 - 注意：RabbitMQ 默认关闭自动 ACK 模式，必须显式调用，否则消息会卡在 unacked 状态
日志必须带 msg.MessageId 才能追踪
Beego 默认日志不含 trace ID，而 RabbitMQ 每条消息都有 msg.MessageId 和 msg.DeliveryTag。多个消费者并行时，日志交织，不带标识根本分不清哪条 log 对应哪条消息。
- 在
handleMsg开头立即生成结构化日志字段：log.WithFields(log.Fields{"msg_id": msg.MessageId, "delivery_tag": msg.DeliveryTag}) - 禁用全局
logs.SetLevel(logs.LevelDebug)，对 RabbitMQ 模块单独启用 debug 级别 - 绝不用
fmt.Printf打印消费日志——它不走 Beego 日志系统，无法统一采集和检索
真正难的不是连上 RabbitMQ，而是让它的连接生命周期、goroutine 并发模型、ACK 语义和错误恢复机制，与 Beego 的启动流程、HTTP 请求模型严格解耦。漏掉其中任一环，都会导致消息堆积、重复消费或静默丢失。
