Iris 不直接使用 gorilla/websocket 原生封装，而是通过 neffos 库统一事件模型与框架生命周期管理，但因此不支持子协议协商、无法在升级前访问原始 *http.Request，且默认启用压缩易致静默断连。
支持，但不是直接暴露 net/http 原生 WebSocket 接口，而是通过内置的 neffos 库封装提供——这意味着你不能直接调用 gorilla/websocket.Upgrade，也不能绕过 Iris 的上下文生命周期去手动控制连接。
为什么 Iris 不用 gorilla/websocket 原生封装？
Iris 选择 neffos 是为了统一事件模型和框架生命周期管理。它把 WebSocket 连接视为一种“长生命周期的 Context”，能自然复用中间件、路由参数、鉴权逻辑；但代价是：不支持子协议协商（如 Sec-WebSocket-Protocol: json），也不暴露底层 *http.Request 给升级前钩子使用。
常见错误现象：neffos 默认启用压缩，若客户端不支持或未协商成功，可能静默断连，且无明确错误日志；升级时若中间件已写入响应头（比如设置了 Content-Type），握手会失败，报错 http: response.WriteHeader on hijacked connection。
- 必须在注册 WebSocket 路由前禁用可能污染响应头的中间件（如日志、压缩）
- 若需基于请求 header 鉴权（如
X-Auth-Token），得在 WebSocket handler 外提前做，或改用websocket.GetContext(conn)从连接中反查上下文 -
neffos的OnConnect回调里无法获取原始*http.Request，只能靠websocket.GetContext拿到有限字段（如 URL、Query）
如何正确注册并启动 WebSocket 服务？
别用 app.Get("/ws", websocket.Handler(...)) 这类旧式写法——Iris v14+ 已弃用该 API。正确路径是显式初始化 neffos 实例，并绑定到 Iris 的 HTTP 路由上。
立即学习“go语言免费学习笔记（深入）”；
实操建议：
- 先执行
go get github.com/kataras/neffos@latest确保版本匹配（Iris v14.2+ 内置的是 neffos v0.0.27+） - WebSocket 路由必须用
app.Any("/ws")或app.Get("/ws")，不能带参数（/ws/{id}会破坏升级流程） - handler 函数签名固定为
func(*neffos.NSConn, *neffos.Message) error，返回非 nil 错误会主动关闭连接 - 广播消息别直接遍历所有连接写，用
ns.Broadcast(&neffos.Message{Body: []byte(...)})，否则并发不安全
示例关键片段：
ws := neffos.New(&neffos.Options{
Upgrader: websocket.Upgrader{
CheckOrigin: func(r *http.Request) bool { return true },
},
})
<p>ns := ws.On("default", neffos.Namespaces{
"chat": neffos.Events{
"message": func(c <em>neffos.NSConn, msg </em>neffos.Message) error {
// 广播给同 namespace 下所有人
return c.Namespace.Broadcast(msg)
},
},
})</p><p>app.Any("/ws", websocket.Handler(ws))
心跳与断线重连怎么处理？
Iris + neffos 不自动发 ping/pong，也**不监听**客户端 ping —— 所有心跳逻辑得自己实现。默认情况下，TCP 层空闲 5 分钟就会被 NAT 或代理切断，而 neffos 不感知这个过程，连接对象仍处于“存活”状态，直到下次写失败才触发 OnError。
容易踩的坑：
- 只在
OnMessage里更新 lastActive 时间，但客户端静默时无法检测掉线 - 用
time.Ticker定期向每个连接发 ping，但没加写锁，高并发下WriteMessage可能 panic - 客户端断线后，
neffos不自动清理连接对象，内存泄漏风险明显
推荐做法：在 OnConnect 启动一个 per-connection goroutine，每 25 秒发一次 ping（留 5 秒 buffer），同时设置 conn.SetWriteDeadline(time.Now().Add(5 * time.Second))；收到 pong 后重置计时器；超时则主动 c.Close()。
消息广播性能瓶颈在哪？
广播慢不是因为网络，而是 neffos 的默认广播机制是串行遍历每个连接并调用 WriteMessage。当在线用户超 500，单次广播延迟可能超过 200ms，且 goroutine 阻塞风险陡增。
关键限制：
-
Conn.WriteMessage默认无超时，一旦某个连接卡住（如弱网客户端），整个广播队列阻塞 - 没有批量写入接口，也无法跳过已断开但尚未 GC 的连接
- namespace 级广播仍需遍历全部连接，无法按房间维度做索引
解决思路：自己维护连接池（map[string]*neffos.NSConn），用读写锁保护；广播前先过滤掉 c.IsClosed() 的连接；对高频消息（如打字状态），改用 UDP 心跳 + WebSocket 补偿，避免全量广播。
真正难的从来不是“连上 WebSocket”，而是连接数涨到几百之后，谁来保证每个 WriteMessage 不阻塞、不丢包、不拖垮整个服务——这些细节，neffos 不替你兜底。
