gorilla/websocket默认不支持广播域划分，因其websocket.Conn是单连接对象，无内置“房间”概念；需手动用sync.RWMutex保护map[string]map[websocket.Conn]bool管理房间，并在join/leave时加锁操作，广播前设WriteDeadline防阻塞，序列化前置、分批并发写以提升性能。
为什么 gorilla/websocket 默认不支持广播域划分
因为它的 *websocket.Conn 是单连接对象，没有内置的“频道”或“房间”概念；所有广播逻辑必须由你手动维护连接集合。直接用一个全局 map[string][]*websocket.Conn 管理房间看似简单，但会引发并发写 panic——map 本身不是并发安全的。
常见错误现象：fatal error: concurrent map writes，尤其在高频率 join/leave 场景下极易触发。
- 必须用
sync.RWMutex或sync.Map包裹房间映射，推荐前者：更易控制读写粒度，且能配合defer mu.Unlock()避免死锁 - 不要把整个连接池塞进一个
sync.Map——它适合 key 存在性判断多、value 变更少的场景；而房间内连接频繁增删，sync.RWMutex + map组合更可控 - 每个房间的连接列表建议用
map[*websocket.Conn]bool而非[]*websocket.Conn，避免遍历时删除切片导致的 index panic 或漏删
如何安全地实现 join/leave + 广播到指定房间
核心是把“连接归属关系”和“消息分发”解耦：连接只注册到房间，广播时再遍历该房间当前存活连接。关键点在于连接断开时必须及时清理——不能依赖 defer 或 recover，而应监听 conn.ReadMessage() 返回的 io.EOF 或 websocket.CloseMessage。
- join 时先加锁，检查房间是否存在，不存在则初始化空 map；再将 conn 写入该房间 map
- leave 时同样加锁，从对应房间 map 中 delete 该 conn，并显式调用
conn.Close()（如果还没关） - 广播前对房间 map 做一次读锁遍历，对每个 conn 调用
conn.WriteMessage()；若写失败（如网络中断），立即 delete 该 conn 并 close —— 否则残留僵尸连接持续占用内存 - 避免在广播循环中做耗时操作（如 JSON 序列化放在广播外完成），否则阻塞整个房间的发送
conn.SetReadDeadline() 和 conn.SetWriteDeadline() 必须配对使用
很多人只设 ReadDeadline 防僵死连接，却忽略 WriteDeadline 导致广播卡住：当某个客户端网络卡顿，WriteMessage() 会无限阻塞 goroutine，最终耗尽 goroutine 数量。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 每次调用
WriteMessage()前必须设置conn.SetWriteDeadline(time.Now().Add(5 * time.Second)) - ReadDeadline 应在每次
ReadMessage()前重置，比如设为 30 秒；超时后主动 close 连接 - 不要复用同一个
time.Time值设 deadline——Go 的 time.Time 是值类型，但多次 SetXXXDeadline 必须传新时间，否则可能被系统缓存旧值 - deadline 错误返回的是
net.ErrTimeout，不是os.IsTimeout()，需用errors.Is(err, net.ErrTimeout)判断
广播性能瓶颈往往出在 JSON 序列化和连接遍历上
当房间有上千连接时，哪怕每个 WriteMessage() 只花 0.1ms，串行广播也要 100ms，用户明显感知延迟。这不是 WebSocket 协议问题，而是实现方式问题。
- 序列化只做一次：
data, _ := json.Marshal(msg)在广播前完成，不要在 for 循环里重复 marshal - 避免锁粒度太粗：不要在整个广播期间 hold 房间 map 的写锁；读锁足够，且应在遍历开始前就释放写锁
- 对超大房间（>500 连接），可考虑分批 goroutine 并行写（每批 50 个），但需注意
conn.WriteMessage()本身不是并发安全的——每个 conn 只能被一个 goroutine 写 - 真正需要横向扩展时，别硬扛单机房间规模；用 Redis Pub/Sub 做跨进程广播，本地只管本机连接，这是更可持续的轻量级方案
房间管理本身不难，难的是在连接生命周期、并发安全、超时控制、序列化开销之间找到平衡点——多数人栽在“以为写完 join/leave 就完了”，其实 disconnect 处理和 deadline 设置才是掉坑最多的地方。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
