Revel框架不内置WebSocket或SSE支持，需绕过其路由和响应生命周期，用原生http.ServeMux+gorilla/websocket手动集成，并自行桥接session、DB、日志等上下文。
Revel 框架本身不内置 WebSocket 或 Server-Sent Events（SSE）支持，它默认基于 net/http 的短连接模型，所以“保持连接”不是开箱即用的能力——你得自己集成底层通信机制，并绕过 Revel 的标准请求生命周期管理。
Revel 中无法直接使用 http.ResponseWriter 升级为 WebSocket 连接
Revel 的拦截器（Interceptor）和控制器方法默认会自动调用 Response.Write() 并结束响应。如果你在 controller 里手动调用 response.Out.WriteHeader() 或尝试复用 response.Out 做长连接，大概率会触发 http: multiple response.WriteHeader calls 或 i/o timeout 错误。
- 根本原因：Revel 在
Filter链末尾强制执行了FinishRequest()，会关闭底层http.ResponseWriter的写入通道 - 不能在
AppController方法中直接操作原始http.ResponseWriter，必须绕过 Revel 的响应封装 - 推荐做法是把 WebSocket 路由从 Revel 的路由系统中剥离，单独注册到
http.ServeMux或fasthttp实例上
用 gorilla/websocket 实现长连接，但需脱离 Revel 路由
最稳妥的方式是放弃让 WebSocket handler 经过 Revel 的 Router 和 Filter 流程，而是直接挂载到 Go 原生 http.ServeMux 上，并确保该路径不被 Revel 的 StaticFilter 或 RouterFilter 拦截。
- 在
app/init.go的init()函数末尾添加：http.HandleFunc("/ws", func(w http.ResponseWriter, r *http.Request) { upgrader := websocket.Upgrader{ CheckOrigin: func(r *http.Request) bool { return true }, } conn, err := upgrader.Upgrade(w, r, nil) if err != nil { http.Error(w, "Upgrade error", http.StatusBadRequest) return } defer conn.Close() // 此处处理消息收发逻辑 }) - 确认
conf/routes中没有GET /ws这类路由定义，否则 Revel 会先抢走请求 - 如果用了 Revel 的
StaticFilter，检查它是否对/ws路径做了通配匹配（默认可能匹配/static/*，但不会影响/ws；不过自定义的Filter可能误伤）
Revel session 与 WebSocket 连接状态无法自动同步
WebSocket 连接建立时，http.Request 中的 Cookie 是可读的，但 Revel 的 session 对象（如 c.Session.Get("user_id")）只在 controller 生命周期内有效。一旦你跳出了 Revel 的调用链，就拿不到已解密/已验证的 session 数据。
- 必须手动解析 Cookie：用
r.Cookie("REVEL_SESSION")拿到值，再用 Revel 的securecookie.DecodeMulti()解密（需从app/conf/app.conf提取app.cookie.secure和app.cookie.secret） - 更简单但有安全风险的做法：在 HTTP 握手阶段通过 query 参数传 token（如
/ws?token=xxx），后端校验 JWT 或数据库 session ID - 切勿在 WebSocket 消息中反复传完整 session 数据——既增大带宽，又增加重放风险
真正麻烦的不是“怎么连上”，而是“连上之后怎么和 Revel 的用户态、日志、配置、DB 连接池等共享上下文”。这些都需要显式桥接，没有魔法接口。比如 DB 连接要从 Revel 的 app.DB 拿，而不是新建一个 sql.Open；日志要调用 revel.INFO.Printf 而非原生 log.Printf。稍不注意，就变成两个独立进程在跑。
