如何使用Golang开发WebSocket服务器_Golang WebSocket实时通信开发

gorilla/websocket 是首选，因标准库无原生 websocket 支持，需手动实现帧解析、ping/pong 等 rfc 6455 逻辑，而 gorilla 已完整验证且持续维护，避免 handshake 失败、掩码校验错误等问题。

为什么 gorilla/websocket 是首选而不是标准库

Go 标准库没有原生 WebSocket 支持，net/http 只能处理 HTTP 协议握手阶段，后续帧解析、ping/pong、连接状态管理全得自己写。直接上手容易卡在 websocket: bad handshake 或连接秒断——因为缺少正确升级头、掩码校验、控制帧响应等逻辑。

用 gorilla/websocket 能绕过这些底层坑，它已通过 RFC 6455 全流程验证，且活跃维护。安装只需：

go get github.com/gorilla/websocket

注意：别用已归档的 golang.org/x/net/websocket，它不支持现代浏览器（如 chrome 90+）的掩码强制策略，会报 websocket: client sent invalid frame。

如何正确处理 WebSocket 连接升级和并发读写

HTTP handler 中不能直接 Write 响应体后再升级，否则会触发 http: multiple response.WriteHeader calls。必须用 Upgrader.Upgrade() 一次性完成握手并获取 *websocket.Conn。

立即学习“go语言免费学习笔记（深入）”；

Upgrader 需显式配置，尤其跨域场景：

var upgrader = websocket.Upgrader{     CheckOrigin: func(r *http.Request) bool {         return true // 生产环境应校验 Origin     }, }

每个连接需分离读写 goroutine，否则 ReadMessage() 和 WriteMessage() 会互相阻塞（WebSocket 协议要求帧有序）。典型结构：

• 主 goroutine 负责 ReadMessage()，解析后发到 channel
• 单独 goroutine 从 channel 拉消息，调用 WriteMessage()
• 用 conn.SetReadDeadline() 防客户端假死，避免 goroutine 泄漏

如何安全广播消息而不 panic

直接遍历连接列表并发写入会触发 concurrent write to websocket connection panic——*websocket.Conn 的写操作不是 goroutine-safe 的。

两种可靠做法：

• 为每个连接配一个专属写 channel（如 chan []byte），写 goroutine 独占消费，广播时向所有 channel 发送副本
• 用 conn.Writejson() 替代 WriteMessage()，它内部加了锁，但仅适合小消息（频繁 JSON 序列化有开销）

别用全局 map 存连接然后 for-range 写，没加锁必崩；也别在 HTTP handler 里直接 conn.WriteMessage()，此时连接可能已被另一 goroutine 关闭。

生产环境必须关掉的默认行为

gorilla/websocket 默认启用 PingHandler 和 PongHandler，但若没设读超时，客户端不发 ping 时连接永不关闭，导致内存泄漏。

必须设置：

• conn.SetReadDeadline(time.Now().Add(30 * time.Second)) 在每次 ReadMessage() 前
• upgrader.HandshakeTimeout = 5 * time.Second 防握手耗时过长
• upgrader.WriteBufferSize = 1024 控制发送缓冲区，避免大消息阻塞

另外，WriteMessage() 失败时不会自动重连，要检查返回 Error 并显式 conn.Close()，否则 fd 会一直占用。