RabbitMQ 在 Revel 中需手动管理连接与信道，无自动配置；应在 app.Init() 初始化全局连接，注册 shutdown hook 优雅关闭；消费者用独立 goroutine 处理，业务函数须无 Controller 依赖；vhost 需显式解析，JSON 消息用 json.RawMessage，大消息需调大 BUFFER_SIZE。
RabbitMQ 在 Revel 框架里没有开箱即用的集成支持，必须手动管理连接、信道和生命周期 —— 这是所有 Go Web 框架接入 RabbitMQ 的共性，Revel 也不例外。
为什么 Revel 不像 Spring Boot 那样自动配置 RabbitMQ
Revel 是一个轻量、无侵入的 Go Web 框架，它不内置消息中间件抽象层，也不提供类似 @RabbitListener 或 RabbitAdmin 的声明式组件。它的设计哲学是“你掌控底层”，所以连接池、重连逻辑、channel 复用、错误恢复都得自己写。
常见错误现象包括：
- 每次 HTTP 请求都新建
amqp.Connection和amqp.Channel，很快触发channel id space exhausted - 服务重启后消费者 goroutine 没有优雅退出，残留连接堆积
- 未设置
connection.NotifyClose()和channel.NotifyClose()，断连后无法自动重建
如何安全地初始化全局连接与信道
Revel 的 app.Init() 是唯一可靠的初始化入口。不要在 controller 里临时建连接，而应把 *amqp.Connection 和复用的 *amqp.Channel 提前准备好，并绑定到 revel.App 或自定义全局变量上。
关键实操建议：
- 使用
amqp.DialConfig设置Heartbeat: 10和ConnectionTimeout: 5 * time.Second，避免网络抖动导致假死 - 每个生产者用途（如发短信、发通知）单独声明一个
Queue，但复用同一个Channel；消费者必须独占Channel（1 consumer per channel） - 在
revel.InterceptFunc中注册 shutdown hook，调用conn.Close()和ch.Close()，否则进程退出时连接不会释放 - 不要用
amqp.Publishing.DeliveryMode = amqp.Transient，生产环境一律设为amqp.Persistent
@RabbitListener 类似功能怎么在 Revel 里实现
Revel 没有注解机制，等效做法是启动时显式启动 goroutine 消费队列，并将 handler 封装成 func(d amqp.Delivery) bool —— 返回 true 表示成功处理并 auto-ack，false 则需手动 d.Nack(false, true)。
典型结构如下：
func startOrderConsumer() {
ch, _ := conn.Channel()
ch.Qos(10, 0, false) // 流控：最多 10 条未确认消息
msgs, _ := ch.Consume("order.queue", "revel-consumer", false, false, false, false, nil)
go func() {
for d := range msgs {
if err := processOrder(d.Body); err != nil {
d.Nack(false, true) // 重回队列
continue
}
d.Ack(false)
}
}()
}
注意：processOrder 必须是纯业务函数，不能依赖 Revel 的 revel.Controller 实例（因为不在 HTTP 请求上下文中），状态和依赖要提前注入。
容易被忽略的三个硬约束
这些不是文档里常提的“最佳实践”，而是线上踩坑后必须硬编码进项目的限制：
- RabbitMQ 的
vhost必须显式指定，Revel 默认不读取amqp://user:pass@host:port/vhost中的 path 部分，要手动从 URL 解析并传给amqp.DialConfig - 所有 JSON 消息体必须用
json.RawMessage解析，避免json.Unmarshal把数字转成float64导致下游 Go 或 Java 服务解析失败 - Revel 的
revel.BUFFER_SIZE默认是 4KB，如果消息体含大附件（如 base64 图片），必须调大或改用流式处理，否则ch.Publish会静默失败
