Revel框架原生不支持WebSocket，需绕过其路由用net/http+gorilla/websocket独立启动/ws服务，并配置Nginx透传Upgrade头及严格校验Origin。
Revel 框架原生不支持 WebSocket
Revel 本身没有内置 WebSocket 处理器，它的 Controller 生命周期和请求模型基于 HTTP 短连接设计，无法直接像 gorilla/websocket 那样升级连接。你如果在 Revel 的 AppController.Get 里调用 w.WriteHeader 或尝试手动操作 http.ResponseWriter，会触发 http: multiple response.WriteHeader calls 错误——因为 Revel 已经在内部写过 header 了。
必须绕过 Revel 路由，用 net/http 直接接管连接
可行路径只有一条：在 Revel 应用启动后，额外起一个独立的 http.ServeMux（或直接用 http.ListenAndServe），监听同一地址但不同路径（如 /ws），并用 gorilla/websocket 处理升级逻辑。Revel 的 HTTP 服务和这个 WebSocket 服务要共存，不能互相干扰。
- 确保 Revel 启动时不占用整个端口的全部路径处理权，即不要让
revel.Run()独占:9000；生产环境建议用revel.NewApp()获取*revel.App实例，再手动集成进自定义http.Server - WebSocket handler 必须注册在
http.DefaultServeMux之外，否则会被 Revel 中间件拦截或重写响应头；推荐用独立http.ServeMux+http.StripPrefix -
gorilla/websocket.Upgrader的CheckOrigin默认拒绝非同源请求，开发时需显式允许：upgrader.CheckOrigin = func(r *http.Request) bool { return true }生产环境应改回严格校验
Revel Controller 怎么与 WebSocket 后端通信
WebSocket 连接生命周期脱离 Revel 控制，所以不能依赖 Controller.Render 或 Controller.Params。你需要用 Go 原生机制桥接：
- 用全局 map 或
sync.Map存储*websocket.Conn，key 可设为用户 ID 或 session token（注意并发安全） - Revel 的 Controller 通过 channel、
pubsub包，或直接调用共享内存中的广播函数向指定连接发消息 - 避免在 WebSocket
ReadMessage循环中调用 Revel 的revel.BEFORE/AFTER钩子——它们不生效，且可能引发 panic - 若需 session 数据，从
http.Request中解析 cookie，再调用revel.SessionStore.Get（需导出 revel 的 session 包，不推荐；更稳妥是复用同一 Redis store）
Nginx 反向代理 WebSocket 时容易漏掉的关键配置
如果 Revel 应用跑在 Nginx 后面，而 WebSocket 走的是同一域名下的 /ws 路径，Nginx 默认不会透传 Upgrade 请求。必须显式开启协议升级支持：
- location 块里必须包含：
proxy_http_version 1.1;<br>proxy_set_header Upgrade $http_upgrade;<br>proxy_set_header Connection "upgrade";
- 不能省略
proxy_set_header Host和X-Forwarded-For，否则Upgrader.CheckOrigin可能因Host变成127.0.0.1:8089而失败 - Revel 应用监听
127.0.0.1:8089，WebSocket 服务也得监听127.0.0.1:8090（或同一端口不同 path），否则 Nginx 无法区分转发目标
最易被忽略的是：Revel 的热重载开发模式（revel run）会 fork 子进程，而独立起的 http.Server 很可能在代码变更后未重启，导致 WebSocket 服务静默失效。上线前务必验证 ws://example.com/ws 是否能真正握手成功。
