Revel框架需手动集成消息队列，关键在异步投递、连接隔离与生命周期管理：WebSocket中用缓冲chan+独立producer goroutine发消息，HTTP控制器用outbox表或拦截器管理；RabbitMQ连接须在app.Init初始化并监听NotifyClose重连，Channel不共享，Publish必设超时，序列化需跨语言兼容。
Revel 框架本身不内置消息队列支持，但它的控制器生命周期清晰、goroutine 友好、结构可扩展，非常适合手动集成 RabbitMQ、Kafka 或 Redis Pub/Sub。关键不是“能不能接”，而是“在哪接、怎么交、怎么收”——尤其要避开阻塞主线程和连接泄漏这两个高频翻车点。
WebSocket 连接中发消息到队列，别在 WS action 里直接 channel.basicPublish
Revel 的 WS 路由（如 WS /chat Application.Chat）接收的是 *websocket.Conn，这个连接对象生命周期长、goroutine 安全性差。如果在 Chat 方法里同步调用 RabbitMQ 的 channel.basicPublish，一旦队列服务抖动或网络延迟，整个 WebSocket 连接会被卡住，客户端感知为“断连”或“卡死”。
- 正确做法：把消息体提取出来后，立刻丢进一个带缓冲的
chan []byte，由单独的 producer goroutine 异步提交 - 必须关闭 channel 时机：在
defer中调用conn.Close()前，向该 channel 发送一个 sentinel 值（如nil），通知 producer 终止该连接对应的消息流 - 避免复用全局
amqp.Connection：每个 producer goroutine 应持有自己的amqp.Channel，或使用连接池（如streadway/amqp的Connection.NotifyClose回调重建）
HTTP 控制器里投递消息，用 revel.Interceptor 管理资源生命周期
比如用户下单成功后要发库存扣减消息，不能在 OrderController.Create 里直接连 RabbitMQ 并 publish。因为 Revel 的拦截器链是同步执行的，而消息发送失败时你既不能 rollback 数据库事务（Revel 不管 DB 事务），也不能简单返回 500（业务已成功）。
- 推荐模式：在 controller 中只写入本地消息表（
outbox表），再用后台 goroutine 定期扫描并投递；或者用revel.BEFORE拦截器注册 cleanup 函数，在请求结束前 flush 待发消息 - 务必设置超时：
channel.Publish调用必须包裹在context.WithTimeout里，防止 broker 假死拖垮整个 HTTP 请求 - 不要共享
amqp.Connection实例给多个 goroutine：官方文档明确要求Connection是线程安全的，但Channel不是；每个 goroutine 应创建自己的Channel
RabbitMQ 连接初始化必须放在 app.Init 阶段，且要处理重连
Revel 的 app.Init 是唯一适合做全局依赖初始化的地方。把 amqp.Dial 放在 controller 里会导致每次请求都新建连接，快速耗尽文件描述符；放错位置还会让连接无法被 revel.Server.Shutdown 正确关闭。
- 必须监听
connection.NotifyClose：RabbitMQ 连接可能因网络闪断、broker 重启等意外关闭，需在回调里触发重连逻辑，而不是等下次 publish 才发现 - 连接字符串里的
heartbeat=30要显式加上，否则默认 0（禁用心跳），Nginx 或云厂商 LB 会在 60s 后主动 kill 空闲连接 - 不要用
guest/guest：生产环境必须创建专用 vhost 和账号，并限制 IP 白名单；Revel 启动时校验连接可用性（例如conn.Channel().QueueDeclarePassive）比运行时报错更可控
最易被忽略的一点：消息体序列化必须与消费者严格一致。Revel 默认用 Go 的 json.Marshal，但如果消费者是 Java Spring Boot，默认反序列化会要求字段首字母大写、有无 omitempty 标签也影响兼容性——这种问题不会在日志里报错，只会静默丢消息。
