WebSocket连接初始化必须用echo.WebSocket，不能直接调http.HandlerFunc；需用echo.WebSocket注册路由、鉴权前置、读写分离、sync.Map管理连接、分组并发广播。
WebSocket连接初始化必须用echo.WebSocket，不能直接调http.HandlerFunc
很多人在Echo里写IM后端时，习惯性把WebSocket处理逻辑塞进普通HTTP路由，结果Upgrade失败、返回400或直接断连。Echo的WebSocket支持不是透传，它封装了gorilla/websocket并做了中间件兼容处理。
正确做法是：用echo.WebSocket注册路由，它会自动设置Upgrade头、禁用响应体写入、绕过常规中间件（如Logger、Recover），避免状态冲突。
-
e.GET("/ws", wsHandler)❌ —— 普通GET，没做协议升级 -
e.GET("/ws", echo.WebSocket(wsHandler))✅ —— 正确入口，wsHandler类型为func(echo.Context, *websocket.Conn) - 别在
wsHandler里调c.JSON()或c.String()，会panic：连接已移交*websocket.Conn - 如果需要鉴权（如校验token），必须在
echo.WebSocket包装前完成，比如用e.GET("/ws", authMiddleware, echo.WebSocket(wsHandler))
*websocket.Conn读写必须配对控制，否则容易触发close sent或use of closed network connection
WebSocket连接是双向流，Echo不帮你管理读写并发安全。常见错误是多个goroutine同时调conn.WriteMessage()，或没关掉读协程就手动conn.Close()，导致底层conn被提前释放。
典型结构应是“一读一写一主控”：
立即学习“go语言免费学习笔记（深入）”；
Echo框架 5.1.0 版本源码包下载，适合关注 RealIP 行为变化、StartConfig.Listener、NewDefaultFS 和观测性中间件入口的开发团队。
- 启动一个goroutine专责
conn.ReadMessage()，收到消息后发到用户专属chan []byte或中心广播队列 - 另一个goroutine从该channel取数据，调
conn.WriteMessage()；注意用conn.SetWriteDeadline()防阻塞 - 主goroutine监听
ctx.Done()或心跳超时，统一触发conn.Close()，并关闭读/写channel - 不要在
ReadMessage()循环里直接调WriteMessage()，TCP层可能阻塞，导致读被卡住，心跳失效
用户连接管理不能只靠map加锁，得结合sync.Map和连接生命周期钩子
IM后端最常写的map[string]*websocket.Conn看似简单，但上线后容易因GC延迟、panic未recover、客户端静默断网等场景，积累大量僵尸连接，拖垮内存和广播性能。
更健壮的做法是：用sync.Map存连接句柄，再配合Echo的context取消机制做软清理：
- 连接建立时，用用户ID作key存入
sync.Map，value是带context.WithTimeout()的封装结构 - 每次心跳或收消息后，重置timeout：
ctx, _ = context.WithTimeout(parentCtx, 30*time.Second) - 在
defer里注册清理函数：defer func(){ connMap.Delete(userID) }() - 避免用
time.AfterFunc单独起goroutine清理——无法感知连接是否已断，易误删 - 广播前先
conn.WriteMessage()试探，捕获websocket.IsCloseError(err)或io.EOF，立刻Delete
消息广播性能瓶颈不在序列化，而在连接遍历和写锁竞争
当在线用户超500，用for range map挨个WriteMessage()，CPU占用飙升、延迟抖动严重。问题核心不是JSON慢，而是每个WriteMessage()都持有一把conn内部互斥锁，串行化写操作。
优化关键点是“合并+异步+跳过”：
- 广播前先用
sync.Pool分配预编码的[]byte，避免每次json.Marshal分配内存 - 把目标连接列表转成切片（
connSlice := make([]*websocket.Conn, 0, n)），避免range sync.Map的迭代开销 - 用
runtime.GOMAXPROCS(1)临时限制作业数，防止写goroutine爆炸；或按每50连接分组，用固定数量worker并发写 - 对长时间未响应的连接（如上次写超时），跳过本次广播，下轮心跳再检查
真实压测中，从单协程遍历3000连接耗时280ms，改成32 worker分组后降到17ms——提升主要来自锁竞争减少，而非CPU提速。
