Revel 框架需手动管理 RabbitMQ 连接与信道：仅在 app.Init 阶段用 revel.OnAppStart 初始化，设心跳与超时；连接全局单例并监听断连重连；每个 goroutine 独占 Channel；HTTP 请求每次新建 Channel 并及时关闭；WebSocket 每连接配独立 producer；消费者 handler 无 Revel 上下文依赖；消息序列化用 json.RawMessage，大消息调大 frame_max；生产环境必须设 Persistent 模式。
Revel 框架不提供消息队列的自动配置，所有连接、信道、重连和生命周期管理都得手动写；直接在 controller 里 amqp.Dial 或复用全局 amqp.Channel 是高频翻车点。
app.Init 阶段初始化 RabbitMQ 连接
这是唯一安全的初始化入口。放错位置会导致连接泄漏、无法优雅关闭，或被 Revel 的并发请求反复新建连接打爆 broker。
- 必须在
app/init.go的init()函数中调用revel.OnAppStart注册初始化逻辑 - 使用
amqp.DialConfig显式设Heartbeat: 10和ConnectionTimeout: 5 * time.Second，避免网络抖动假死 - 连接对象存为全局变量（如
var conn *amqp.Connection），不要塞进revel.App或 controller 实例 - 务必监听
conn.NotifyClose()并启动重连 goroutine —— 断连后不会自动恢复，不处理就永久失联
每个生产者 goroutine 独占 amqp.Channel
amqp.Connection 是线程安全的，但 amqp.Channel 不是。共享 channel 会导致 channel id space exhausted 错误，尤其在 WebSocket 场景下高发。
- HTTP 控制器投递消息时：每次请求新建
ch, err := conn.Channel()，用完立刻ch.Close() - WebSocket 消息投递时：为每个连接启动独立 producer goroutine，并持有自己的
amqp.Channel - 别用连接池封装
Channel—— RabbitMQ 官方明确建议“1 consumer per channel”，复用反而增加竞争和错误概率 -
channel.basicPublish必须包裹在context.WithTimeout中，超时时间建议 ≤ 3s，防止 broker 假死拖垮整个 HTTP 请求
消费者用独立 goroutine 启动，handler 不能依赖 Controller
Revel 没有类似 @RabbitListener 的注解机制，等效做法是进程启动时显式运行消费逻辑，且 handler 必须无框架上下文依赖。
- 在
OnAppStart中调用startOrderConsumer()类函数，内部新建ch, _ := conn.Channel() - handler 类型固定为
func(d amqp.Delivery) bool：返回true自动 ack，false需手动d.Nack(false, true) - handler 内禁止调用
c.RenderJSON、c.Session或任何*revel.Controller方法 —— 此时没有请求上下文 - 若需 DB 操作，应提前初始化好
*sql.DB或*gorp.DbMap并传入 handler，而非从 controller 获取
序列化与消息体设计要跨语言兼容
Revel 只管投递，不负责序列化。用 json.Marshal 很常见，但要注意字段命名、空值处理和大消息边界。
- 推荐用
json.RawMessage接收和转发消息体，避免重复 unmarshal/marshal 性能损耗 - 结构体字段必须首字母大写 +
json:tag，否则序列化为空对象 - 大消息（>128KB）需调大 RabbitMQ 服务端
frame_max和客户端amqp.Config.FrameSize，否则报frame size exceeded - 别用
amqp.Publishing.DeliveryMode = amqp.Transient—— 生产环境一律设amqp.Persistent，否则节点重启消息丢失
最易被忽略的是 Channel 的生命周期绑定粒度：它必须和业务场景对齐 —— WebSocket 连接生命周期对应一个 Channel，HTTP 请求对应一个 Channel，后台消费者也各自独占 Channel。混用看似省资源，实则埋下竞态和连接耗尽的隐患。
