何之源写WebSocket多人在线应用，绕不开一个经典问题：连接怎么管。Golang做WebSocket服务端，最常见的场景就是聊天室、协同白板、多人游戏匹配，这类应用里消息不能满世界广播，得按逻辑分组发。这个“组”在业务上就是“房间”，比如聊天频道、对局房间、直播弹幕分区。标题里这个“房间分组管理连接群组”的需求，说白了就是解决一件事：怎么让服务端快速知道“这条消息该发给哪些连接”，并且在高并发下不出错、不泄漏、不互相干扰。
这篇文章我直接基于自己的实战经验，把Golang + WebSocket实现按房间分组管理连接的完整方案拆开讲。从核心架构选型、代码骨架、房间注册与广播机制、并发安全，到常见坑和排查思路，一次性说透。适合刚接触WebSocket服务端开发、或者已经写过简单回显服务但不知道怎么组织多房间连接的开发者参考。
1. 项目概述与整体设计思路
1.1 核心需求解析：什么是“房间”，为什么需要按房间分组
先明确一个概念：WebSocket本身只有“连接”这个概念，没有“频道”也没有“分组”。客户端连上服务器后，服务端拿到的是一个独立的*websocket.Conn对象，所有消息都是点对点在服务端和这个连接之间走。但业务上我们需要“一条消息发给一批人”，比如A用户在聊天室发了一句“大家好”，这句消息得推给同房间的所有人，而不是全服所有人，也不是只有服务器自己知道。
如果连接很少，比如几十个，全量遍历所有连接挨个匹配房间号再发送，性能上也能扛。但连接一旦上千、上万，每次广播都O(n)扫描一遍所有连接，CPU和内存都会迅速恶化。更麻烦的是，连接会反复建立和断开，你得频繁增删全局连接列表，并发操作下还可能产生数据竞争。
按房间分组管理，本质上是把这个“遍历查找”变成“哈希定位”。每个房间维护一个自己的连接集合，消息进来先定位房间，再遍历这个房间内的连接发送。这样每次广播的规模从“全部连接数”缩小到“单个房间连接数”，复杂度从O(全连接)降到O(单房间人数)，而且全局连接状态可以通过统一注册表管理，增删连接都有明确入口，不会出现连接重复加入、消息漏发或者并发读写同一连接的问题。
1.2 整体架构：从单连接管理到房间分组，Hub 模式的选择
网上聊Golang WebSocket的教程，很多只写到“echo回显”或者“单连接收发消