beego不内置rabbitmq支持，必须直接使用amqp091-go；常见坑包括启动时裸调amqp.dial()致panic、consumer绑定http生命周期致ack失败、日志无消息id难追踪、dns未就绪即dial、channel并发不安全。
Beego 本身不提供 RabbitMQ 封装，直接用 amqp091-go 才是唯一可靠路径；强行套用 Beego 生命周期管理 Consumer 会导致 ACK 失败、消息重复投递。
Beego 启动时调用 amqp.Dial() 导致服务起不来
Beego 的 app.Run() 是阻塞调用，如果在 main() 或 init() 里裸调 amqp.Dial()，DNS 未就绪、网络不通或 RabbitMQ 未启动，就会 panic 并退出进程，HTTP 服务根本起不来。
- 必须把连接初始化包装成带重试、超时和错误日志的函数，例如用
sync.Once+time.AfterFunc延迟执行 - 从
beego.AppConfig.String("rabbitmq::url")读配置，不要硬编码 URL - 连接失败时仅记录
warn日志，设置全局状态如rabbitmq.status = "unavailable"，让 Web 接口降级为同步处理或返回队列不可用提示 - 避免在
beego.AppInit()中同步 Dial —— 它仍处于主线程，一样会卡住启动
ch.Consume() 写在 Controller 里导致 ACK 永远发不出去
常见错误写法：在 Controller.Get() 中调用 ch.Consume()，然后 for range msgs 循环处理。HTTP 请求一结束，goroutine 被回收，msg.Ack() 根本没机会执行，RabbitMQ 认为消息超时未确认，反复重发。
- Consumer 必须作为独立长任务，在
beego.AppInit()阶段用go func() { ... }()启动，与 HTTP 生命周期完全解耦 - ACK 动作必须由该 goroutine 自己完成，不能跨 goroutine 调用任何 Controller 方法或依赖 request context
- 若需回传结果（如更新订单状态），用
sync.Map缓存处理结果，或往本地chan/ Redis 写入标识，再由另一个定时任务或接口轮询拉取
日志混杂、消息 ID 缺失导致线上问题无法定位
Beego 默认日志无 trace ID，而 RabbitMQ 每条 amqp.Delivery 有 MessageId 和 DeliveryTag。多个消费者并行时，日志交织，根本分不清哪条 log 对应哪条消息。
- 在
msgs循环开头立即打结构化日志：log.WithFields(log.Fields{"msg_id": msg.MessageId, "delivery_tag": msg.DeliveryTag}) - 禁用全局
logs.SetLevel(logs.LevelDebug)，只对 RabbitMQ 模块单独启用 debug 级别 - 绝对不用
fmt.Printf打消费日志 —— 它绕过 Beego 日志系统，无法统一采集和按字段过滤
真正难的不是连上 RabbitMQ，而是让 Consumer 在 Beego 进程生命周期内稳定存活、正确 ACK、可追溯。所有“封装成 Beego 插件”的尝试，最终都会撞在 goroutine 管理和上下文隔离这堵墙上。
