Golang轻量级WebSocket广播域逻辑划分实现-Golang-PHP中文网

gorilla/websocket默认不支持广播域隔离，因其*websocket.conn仅为单连接抽象，无内置房间或分组概念；广播需手动遍历、筛选并加锁，否则易引发并发写panic、漏发或部分客户端收不到消息。

golang轻量级websocket广播域逻辑划分实现

因为它的 *websocket.Conn 是单连接抽象，没有内置“房间”或“分组”概念。所有连接都平铺在内存里，广播时必须手动遍历、筛选、加锁——稍不注意就出现并发写 panic 或漏发。

常见错误现象：concurrent write to websocket connection、广播只到部分客户端、新连接加入后收不到历史消息。

核心是把“连接 → 分组”和“分组 → 连接集合”两层映射拆开，避免每次广播都扫全量连接。

Golang Uber Dig

使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等

下载

推荐结构：groupMap *sync.Map 存 groupID → *sync.Map（值是该组内所有 *websocket.Conn 的集合），每个子 sync.Map 用连接指针作 key、空 struct 作 value（节省内存）。

连接加入时：先根据 token/URL 参数解析出 groupID（如 /ws?room=chat-a 中取 chat-a），再用 LoadOrStore 获取对应子 map，然后 Store(conn, struct{}{})
广播时：先 Load 出目标 groupID 对应的子 map，再用 Range 遍历发送——范围可控，无冗余判断
连接断开时：必须从所属子 map 中 Delete(conn)；若子 map 变空，可选地从 groupMap 中 Delete(groupID) 防止内存泄漏

*websocket.Conn.WriteMessage 本身不是 goroutine 安全的——多个 goroutine 同时调用会触发 concurrent write panic。

每个连接必须绑定一个专属的写协程（writePump），所有广播消息都通过 channel 推送给它；这是最稳妥的方案
如果坚持同步写（比如小规模内部系统），务必对每个 conn 加独占 mutex，且锁粒度不能跨连接——别用一把大锁包住整个广播循环
注意 SetWriteDeadline 必须在每次 WriteMessage 前设置，否则超时不生效；广播场景建议设为 time.Now().Add(5 * time.Second) 防卡死
遇到 websocket: close sent 或 i/o timeout 错误时，立即关闭连接并从所在 group 的子 map 中移除，否则下次广播还会尝试写已失效连接

纯内存方案（如 sync.Map）天然不支持多实例部署。若需横向扩展，必须引入外部协调机制，但又不能重蹈 Redis Pub/Sub 的高延迟或消息丢失坑。

轻量级解法：用 Redis Streams + 每个实例本地 group cache。写入用 XADD，各实例用 XREADGROUP 拉取本实例负责的 group 消息，再投递到对应本地连接池——延迟可控在 10ms 内
避免用 Redis 的 PUBLISH/SUBSCRIBE：它不保证消费可达，且无法按 group 做精确路由
更轻的替代：若仅需单机多进程（如 systemd 多 worker），可用文件锁 + mmap 共享内存模拟 group 映射表，但调试成本高，一般不推荐
真正容易被忽略的一点：groupID 命名空间要预留层级，比如 tenant:project:room，否则后期合并租户或拆分项目时，广播逻辑要重写