Revel 框架不内置消息队列支持，集成 RabbitMQ 需手动管理 AMQP 连接与 Channel 生命周期：必须在 AppInit 中单例初始化连接并挂载到 revel.App，Controller 中每次请求新建 Channel 并 defer 关闭；消费者需独立 goroutine 运行，绑定 Revel Shutdown 信号实现优雅退出；消息体应使用明确 struct 序列化，避免直接传递 revel.Params 或 request。
Revel 框架本身不内置消息队列支持，集成 RabbitMQ 必须手动引入 AMQP 客户端并管理连接生命周期——直接在 controller 里每次 amqp.Dial 建连会快速耗尽文件描述符，这是最常踩的坑。
为什么 Revel 不像 Spring Boot 那样有 @RabbitListener
Revel 是 Go 语言的 MVC 框架，设计哲学偏向显式、轻量、无魔法。它没有运行时 AOP 或注解处理器，因此无法自动扫描和绑定消费者方法。所有 RabbitMQ 的连接、channel 复用、错误重连、消息确认（channel.Ack / channel.Nack）都得你自己写。
关键点：
- 不能把
amqp.Connection或amqp.Channel当局部变量在每个 HTTP handler 里创建——连接开销大，且 Go 的amqp库不是 goroutine-safe 的 channel，多协程并发用同一个channel会 panic - 必须用单例或依赖注入方式持有
*amqp.Connection，再按需从它派生*amqp.Channel - Revel 的
app.Init是初始化全局资源（如 RabbitMQ 连接）的合理位置，但要注意：若连接失败，revel.Run()会直接退出，不能“静默降级”
如何安全复用 amqp.Connection 和创建 Channel
在 app/init.go 中初始化连接，并挂到 Revel 的 revel.App 上：
func init() {
revel.InterceptMethod((*App).Begin, revel.BEFORE)
revel.InterceptMethod((*App).End, revel.AFTER)
revel.FILTERS = append(revel.FILTERS, revel.PanicFilter)
}
func AppInit(revel *revel.Revel) {
// 初始化 RabbitMQ 连接
conn, err := amqp.Dial("amqp://guest:guest@localhost:5672/")
if err != nil {
revel.ERROR.Printf("Failed to connect to RabbitMQ: %v", err)
panic(err) // Revel 启动阶段失败必须 panic，否则服务不可用
}
revel.App.Set("rabbitmq.conn", conn)
// 可选：预热一个 channel 用于健康检查
ch, _ := conn.Channel()
ch.Close()
}
在 controller 中获取 channel 的正确姿势（每次请求新建，用完关闭）：
- 调用
revel.App.Config.StringDefault("rabbitmq.url", "amqp://...")获取配置，避免硬编码 - 从
revel.App.Config读取revel.App.Get("rabbitmq.conn").(*amqp.Connection)，再调用.Channel() -
必须 defer ch.Close()，否则 channel 泄漏，RabbitMQ 侧会报
too many channels - 不要 defer conn.Close() —— 这是全局连接，关了整个服务就断连了
消费者怎么跑起来且不被 Revel 生命周期干扰
Revel 是 HTTP-first 框架，没有内置的后台 goroutine 管理机制。你写的消费者必须自己启停，且要和 Revel 的 shutdown 流程对齐。
推荐做法：
- 在
app/init.go的AppInit末尾启动一个长期运行的 goroutine，例如：go startRabbitMQConsumer(revel.App) - 消费者内部用
for msg := range msgs循环，处理完调用msg.Ack(false)；失败时用msg.Nack(true, true)重回队列（注意第二个true表示 requeue） - 监听 Revel 的 shutdown 信号（
revel.Shutdownchannel），收到后主动调用ch.Cancel、msgs.Close()，再等待正在处理的消息结束 - 切勿用
time.Sleep等待，要用sync.WaitGroup+context.WithTimeout控制优雅退出时间
消息体序列化与 revel.Params 冲突怎么避
Revel 的 revel.Params 是 URL/query/form 解析后的 map，而 RabbitMQ 消息体是 raw []byte。常见错误是直接把 json.Marshal(req.Params) 发过去，结果丢失类型信息或嵌套结构错乱。
正确做法：
- 定义明确的 Go struct（如
type OrderCreatedEvent struct { OrderID string `json:"order_id"` }），只序列化业务字段 - 避免传
*revel.Request或revel.Params到消息中——它们含大量 HTTP 元数据，且非 JSON 友好 - 消费者端反序列化时，用
json.Unmarshal(msg.Body, &event)，而非msg.Body直接当字符串用 - 如果需要 traceID 透传，手动从
req.Id提取，塞进 event struct，别依赖 Revel 的上下文传递机制（它不跨进程）
最易被忽略的是 channel 关闭时机和消费者 goroutine 的生命周期绑定——Revel 不会帮你等 consumer 处理完最后一条消息才退出，这需要你用 context 和 WaitGroup 显式控制，否则 SIGTERM 后可能丢消息。
