Golang轻量级WebSocket多房间聊天实现-Golang-PHP中文网

必须为每个房间维护独立的 sync.map[*websocket.conn]struct{} 和写协程，禁止全局连接池广播；服务端校验 token 绑定 room/user，消息只信任服务端注入字段；空闲房间需定时清理。

golang轻量级websocket多房间聊天实现

如何用 `gorilla/websocket` 实现多房间隔离

直接结论：不能靠单个全局连接池，必须为每个房间维护独立的 map[*websocket.Conn]bool 或更稳妥的 sync.Map。 Gorilla 的 *websocket.Conn 是单次读写绑定的，不支持广播，得自己做分发。

常见错误是把所有连接塞进一个 map，然后对全量连接 broadcast——结果是 A 房间发的消息被 B 房间用户收到。房间隔离的本质是消息路由前先按 room ID 过滤连接集合。

每个房间对应一个独立结构体，至少包含：id string、clients sync.Map（key 为 *websocket.Conn，value 可设为 struct{}）、mu sync.RWMutex（保护广播时遍历）
客户端连接时，URL 带 room=xxx 参数，服务端用 r.URL.Query().Get("room") 提取，再查或创建对应房间实例
不要在 conn.ReadMessage() 循环里直接向其他 conn 写——可能阻塞，应转发到房间的 channel 或 worker goroutine 处理

`conn.WriteMessage()` 并发安全吗？怎么避免 panic: concurrent write to websocket connection

不安全。同一个 *websocket.Conn 的 WriteMessage() 方法不是并发安全的，多个 goroutine 同时调用会触发 panic。

典型场景：A 用户发消息 → 房间广播 → 多个 client conn 同时被遍历并调用 WriteMessage() → 如果某个 conn 正在读（比如心跳响应），就可能撞上写。

每个 conn 必须配一个专属的写协程 + 消息 channel，例如：writeCh chan []byte，只由该协程从 channel 读并调用 WriteMessage()
房间广播时，只把消息 send 到每个 client 的 writeCh，不直接调用 WriteMessage()
务必在连接关闭时 close channel 并 stop 写协程，否则可能泄漏 goroutine 和阻塞 send

如何设计消息格式让房间和用户身份不被伪造

前端控制的字段（如 room、username）不可信，必须服务端校验并剥离。WebSocket 连接建立后，第一帧应是认证消息，服务端验证通过才允许加入房间。

Golang Naming

Go（Golang）命名规范 — 包括包、构造函数、结构体、接口、常量、枚举、错误、布尔值、接收器、getter/setter、函数等。

下载

推荐流程：HTTP 升级前先走一次 /join?token=xxx&room=xxx 接口签发短期有效的 join token（含 room、user_id、exp），升级时带上 token，服务端解析并绑定 room 和 user identity 到 conn 上下文。

消息体用 JSON，但只信任服务端注入的字段：room_id（来自 token）、user_id（同上）、content（客户端提供，长度限制 512 字节）
禁止客户端在消息里传 room 或 to 字段，广播逻辑完全由服务端根据 conn 绑定的 room 决定
如果需私聊，走单独 endpoint（如 POST /msg/private），不在 WebSocket 通道里解析目标用户

为什么不用 `gobwas/ws` 而坚持用 `gorilla/websocket`

gobwas/ws 更轻、零依赖，但生产环境容易踩坑：它默认不处理 PING/PONG，也缺少对 CloseMessage 的健壮封装，客户端断连后服务端常滞留连接；而 gorilla/websocket 的 SetPingHandler、SetPongHandler、EnableWriteCompression 都开箱即用。

多房间场景下，连接生命周期管理比“轻”更重要。 Gorilla 的 conn.SetReadDeadline() 配合 for { conn.ReadMessage() } 循环能稳定检测断连；gobwas 需手动轮询 conn.State()，且无标准心跳 fallback。