结论：用 gorilla/websocket + goroutine + channel 组合比套框架更稳、可控、易调优；gin/echo 仅适合 http 接口，websocket 必须独立实现升级与连接管理，关键在于禁用 keep-alive、正确使用 send channel、设写超时和心跳 handler。
直接说结论：用 gorilla/websocket + goroutine + channel 组合，比套任何“框架”更稳、更可控、更易调优。Gin 或 Echo 仅适合做 HTTP 接口层，WebSocket 连接管理必须自己写。
为什么别用 Gin/Echo 做 WebSocket 主干
很多人一上来就用 Gin 路由挂 websocket handler，结果卡在三个地方：
- HTTP 中间件（如 JWT 验证）会阻塞 upgrade 流程，
upgrader.Upgrade()必须在中间件执行完前调用，否则返回 400 -
Gin的 context 生命周期和 WebSocket 连接生命周期不匹配——连接可能存活数小时，而c在 handler 返回后就被回收 - 广播逻辑若塞进 Gin handler，容易误用
c.Writer写 WebSocket 消息，实际该用conn.WriteMessage()
正确做法是：Gin 只管登录、拉取历史消息、创建群组等 REST 接口；WebSocket 升级走独立 http.HandleFunc，完全绕过 Gin。
upgrader.Upgrade() 前必须关掉 HTTP keep-alive
常见静默失败：浏览器连上了，但发不出第一条消息，服务端也收不到。根本原因是 Go 的 http.Server 默认开启 Keep-Alive，而 WebSocket upgrade 是一次性协议切换，不能复用底层 TCP 连接。
解决方法是在启动 server 时显式关闭：
srv := &http.Server{
Addr: ":8080",
Handler: nil, // 不用 Gin 的 handler
ReadTimeout: 10 * time.Second,
WriteTimeout: 10 * time.Second,
IdleTimeout: 0, // 关键：禁用 keep-alive
}
同时，upgrader 要设 CheckOrigin 和缓冲区大小：
var upgrader = websocket.Upgrader{
CheckOrigin: func(r *http.Request) bool { return true },
ReadBufferSize: 1024,
WriteBufferSize: 1024,
}
广播不能用“for range clients + go write”模式
这是最典型的 goroutine 泄漏源。每条消息起一个 goroutine 遍历所有 client，用户量到 500+ 就开始 GC 抖动，内存暴涨。
正确结构是单广播协程 + 每 client 独立 send channel：
- 每个
Client结构体带一个send chan []byte - 广播时只往每个 client 的
sendchannel 发消息，不阻塞主逻辑 - client 的
writePumpgoroutine 从自己的send取数据并调conn.WriteMessage() - 断连时必须
close(client.send)，且writePump中用select { case msg, ok := 安全退出
漏掉 close 或没判 ok，channel 就永远阻塞，goroutine 卡死不回收。
conn.WriteMessage() 前不设 deadline 就等于裸奔
现象：某 client 网络抖动后，后续所有广播都卡住，日志里看不到错误，但新消息发不出去。
原因：WebSocket 写操作默认无超时，底层缓冲区满或网络卡住时，WriteMessage 会永久阻塞 goroutine。
必须每次写前设截止时间：
err := conn.SetWriteDeadline(time.Now().Add(10 * time.Second))
if err != nil {
return err
}
defer conn.SetWriteDeadline(time.Time{}) // 清除，避免影响下次写
return conn.WriteMessage(websocket.TextMessage, data)
还要配对心跳：
conn.SetPingHandler(func(appData string) error {
return conn.SetWriteDeadline(time.Now().Add(10 * time.Second))
})
conn.SetPongHandler(func(string) error {
return conn.SetReadDeadline(time.Now().Add(10 * time.Second))
})
没设 Ping/Pong handler，连接会在 1 分钟后被静默关闭，但你的广播逻辑还把它当活跃 client，导致消息丢失。
真正难的不是写通连接，而是让成百上千个连接长期稳定在线——超时控制、channel 关闭时机、心跳保活，三者缺一不可。少设一个 SetWriteDeadline，线上跑两天就出问题。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
