Revel 框架不支持原生 WebSocket，因其基于同步 HTTP 生命周期，无法在控制器中安全升级连接；必须通过 gorilla/websocket 等独立服务解耦实现，并用 Redis Pub/Sub 或 token 鉴权共享上下文。
Revel 框架本身不内置 WebSocket 服务，也没有原生的实时推送能力；它默认是同步、阻塞式 HTTP 框架。想用 Revel 做实时消息推送，必须外挂异步通信层——常见做法是用 Revel 处理业务逻辑（如创建任务、更新状态），再通过 Redis Pub/Sub 或 WebSocket server（如 gorilla/websocket）中转消息到前端。直接在 Revel 控制器里启一个长连接或轮询接口，会吃光 goroutine 资源，很快崩。
为什么不能直接在 Revel 控制器里写 WebSocket handler
Revel 的请求生命周期基于 net/http，每个请求独占一个 goroutine，且默认不支持升级为 WebSocket 连接（Upgrade 需要绕过 Revel 中间件链和响应包装）。强行在 Controller.Action 里调用 response.Upgrade() 会导致 panic 或连接异常关闭，因为 Revel 已经开始写 header 和 body 流了。
- Revel 的
Result接口设计是单向输出，无法中途切换协议 - 所有中间件（如 session、flash、filter）都会被执行，干扰 WebSocket 握手
- 开发模式下热重载会 kill 正在运行的 WebSocket 连接，导致频繁断连
推荐架构：Revel + gorilla/websocket 独立服务
把实时通道从 Revel 主流程剥离，用独立的 gorilla/websocket 服务监听另一个端口（如 :8081），Revel 应用只负责发通知——比如状态变更后往 Redis 的 channel:notifications 发一条 JSON 消息，WebSocket 服务订阅该 channel 并广播给在线客户端。
- WebSocket 服务用标准 Go 启动，不依赖 Revel，避免框架约束
- Revel 和 WebSocket 服务之间用
Redis Pub/Sub或HTTP POST（轻量级）解耦 - 前端用
new WebSocket('ws://your-domain.com:8081')直连，不走 Revel 的路由 - 需要鉴权时，在 WebSocket 握手阶段读取 cookie 或 query 参数，调用 Revel 提供的
/api/auth/verify接口校验 token
如何让 Revel 和 WebSocket 服务共享用户上下文
Revel 默认用加密 cookie 存 session，但 gorilla/websocket 拿不到这个 session 数据。最稳的方式是：前端登录后，Revel 返回一个短期有效的 connection_token（JWT 或随机字符串），存入 Redis 并设置 5 分钟过期；WebSocket 服务在 Upgrader.CheckOrigin 或 Upgrade 后立刻验证该 token，查 Redis 是否存在并匹配用户 ID。
- 不要把 Revel 的 session cookie 直接透传给 WebSocket，跨域时浏览器不会发送
- 避免在 WebSocket 连接建立后再频繁查数据库，用 Redis 缓存用户角色、频道权限等关键信息
- 如果使用
Revel.RunMode == "prod"，确保 WebSocket 服务也禁用调试日志，防止 goroutine 泄漏
真正难的不是连上 WebSocket，而是连接保活、断线重连时的状态同步、消息去重和离线消息兜底——这些逻辑全得自己写，Revel 不帮你扛。别指望靠改几行 Revel 配置就搞定实时推送，它只是个 HTTP 路由和模板引擎，不是消息中间件。
