Go聊天室稳定核心是守住WebSocket生命周期、防goroutine泄漏、正确广播；须用gorilla/websocket设CheckOrigin、读写超时、单goroutine写+chan广播、PongHandler响应ping，禁用全局锁map。
Go 语言实现聊天室，核心不是写多少代码，而是守住 WebSocket 连接生命周期、避免 goroutine 泄漏、正确广播消息——多数失败案例都栽在这三点上。
怎么用 gorilla/websocket 建立稳定连接
别直接用标准库 net/http 拼 WebSocket 升级逻辑，它不处理帧校验、ping/pong、连接状态等细节。用 gorilla/websocket 是事实标准。
关键点：
-
Upgrader.CheckOrigin必须显式设为func(r *http.Request) bool { return true }或按需校验，否则跨域请求直接 403 - 调用
upgrader.Upgrade()后，*websocket.Conn就接管了底层 TCP 连接，后续不能再读写http.ResponseWriter - 务必在
defer conn.Close()前设置读写超时：conn.SetReadDeadline(time.Now().Add(30 * time.Second))，否则空闲连接会一直挂着
怎么安全地管理在线用户和广播消息
不能用全局 map + 普通互斥锁（sync.Mutex）存连接，因为 WriteMessage 可能阻塞，锁住整个 map 会导致广播卡死。
立即学习“go语言免费学习笔记（深入）”；
推荐做法：
- 每个连接启一个 goroutine 专门读消息：
for { _, msg, err := conn.ReadMessage(); ... } - 所有写操作走单个“广播 goroutine”：用
chan []byte接收待发消息，循环遍历在线连接列表并调用conn.WriteMessage() - 连接断开时，从用户 map 中删掉它，并关闭该连接专属的
donechannel，通知广播协程跳过它 - 每次
WriteMessage前检查conn.IsClosed()（需用conn.CloseHandler()配合），避免 panic: “write tcp: use of closed network connection”
为什么客户端收不到消息？常见错误链
典型现象是服务端日志显示“已广播”，但浏览器 console 里 onmessage 没触发。原因往往不在 Go 侧，而在协议或客户端配合上：
- 服务端没响应 ping 帧 → 客户端主动断连 →
Upgrader.PongHandler()必须设置，哪怕只写conn.SetPongHandler(nil) - 广播时用了
websocket.TextMessage，但前端event.data是Blob类型 → 检查前端是否加了ws.binaryType = 'arraybuffer'干扰了文本解析 - 消息体含中文却没设 UTF-8 →
conn.WriteMessage(websocket.TextMessage, []byte("你好"))是安全的，但若拼接了非 UTF-8 字节，Chrome 会静默丢弃整帧 - 并发写同一连接 →
WriteMessage不是线程安全的，必须确保单连接只有一个 goroutine 负责写
要不要加 Redis 或消息队列？
单机部署时完全不需要。WebSocket 连接本质是长连接，消息广播走内存就够了。加 Redis 只会引入序列化开销、网络延迟、连接池管理复杂度，还解决不了 goroutine 泄漏或连接粘包问题。
只有当你要做多实例横向扩展、或者需要离线消息持久化时，才考虑把“广播指令”发到 Redis Pub/Sub，各实例自己维护本地连接列表。但此时你面对的已不是“聊天室”，而是分布式实时推送系统——那已经是另一个工程权衡了。
真正容易被忽略的是连接异常退出后的资源清理：比如用户关浏览器标签页，TCP 连接不会立刻断，得靠 SetReadDeadline + io.EOF 捕获来触发清理，而不是等操作系统回收。漏掉这点，跑一天后 netstat -an | grep :8080 | wc -l 就会远超真实在线人数。
