Beego不提供消息队列抽象层，需手动集成amqp091-go等SDK；须避免裸调Dial、禁止Consumer绑定HTTP生命周期、需独立goroutine运行并手动ACK，且日志须携带消息ID以保障可追踪性。
Beego 框架本身不提供消息队列的抽象层或内置客户端，所谓“集成”其实是手动引入并管理第三方 SDK（如 amqp091-go 或 rocketmq-client-go/v2），再将其生命周期与 Beego 应用对齐。直接调用 SDK 初始化、裸写消费循环、混用 HTTP 上下文处理 ACK——这些都会导致 panic、消息丢失或服务启动失败。
Beego 启动时初始化 RabbitMQ 连接容易 panic
Beego 的 app.Run() 是阻塞调用，若在 main() 或 init() 中同步执行 amqp.Dial() 且网络不通、DNS 未就绪或认证失败，服务会直接退出，而不是降级运行。
- 不要在
func main()里裸调amqp.Dial()；应包装为带超时、重试和错误日志的初始化函数 - 推荐读取配置后用
sync.Once+time.AfterFunc延迟初始化，避免阻塞启动流程 - 连接失败时，Beego 应继续启动 HTTP 服务，但需标记
rabbitmq.status = "unavailable"并记录warn日志，而非fatal
Consumer goroutine 必须脱离 Controller 生命周期独立运行
常见错误是把 ch.Consume() 放进 Controller.Get() 里，然后用 for range 循环消费——这会让消费者逻辑被绑死在单次 HTTP 请求生命周期内。请求一结束，goroutine 被回收，msg.Ack() 就永远发不出去，消息持续重复投递。
- Consumer 必须作为独立长任务运行，例如在
beego.AppInit()阶段启动：go func() { ... }() - 绝对不要在 Controller 方法体内部启动消费循环；ACK 必须由该 goroutine 自己完成
- 若需将消息处理结果回传给 Web 层（如更新订单状态），应通过
sync.Map、本地chan或 Redis 缓存中转，而非跨 goroutine 调用 Controller 方法
日志无消息 ID 导致多消费者场景下无法追踪
Beego 默认日志不含 trace ID，而 RabbitMQ 每条消息都应有唯一标识（如 msg.MessageId 或自增序号）。当多个消费者并行处理时，日志交织，根本分不清哪条 log 对应哪条消息。
- 在
amqp.Delivery处理开头立即生成结构化字段：log.WithFields(log.Fields{"msg_id": msg.MessageId, "delivery_tag": msg.DeliveryTag}) - 禁用
Beego的logs.SetLevel(logs.LevelDebug)全局开关，对 RabbitMQ 模块单独启用 debug 级别日志 - 避免使用
fmt.Printf打印消费日志——它不走 Beego 日志系统，无法统一采集
真正难的不是连上 RabbitMQ，而是让它的生命周期、并发模型和错误恢复机制与 Beego 的启动流程、HTTP 请求模型不冲突。很多问题表面是 SDK 用法不对，根子是把 Beego 当成了“全托管框架”，忽略了 Go 原生并发语义必须自己兜底。
