gorilla/websocket本身不支持房间概念，必须手动实现广播域逻辑；直接用map[string][]websocket.Conn会因并发写和遍历删除引发panic，且WriteMessage()非并发安全，需用sync.RWMutex+map[conn]bool管理房间、单连接专属writePump协程及每次写前设WriteDeadline来解耦生命周期与广播。
gorilla/websocket 本身不带房间概念，所有广播域逻辑必须手动实现；不做解耦，迟早遇到 concurrent map writes、concurrent write to websocket connection、部分客户端收不到消息这三类问题。
为什么不能直接用 map[string][]*websocket.Conn 管理房间
map 本身不是并发安全的，map[string][]*websocket.Conn 在高频率 join/leave 场景下必然触发 fatal error: concurrent map writes。即使加了锁，切片在遍历时删除元素也会导致 index panic 或漏删。更隐蔽的问题是：广播时若直接遍历切片并调用 conn.WriteMessage()，多个 goroutine 同时写同一个 conn 会 panic concurrent write to websocket connection。
推荐做法：
- 房间映射用
sync.RWMutex包裹的map[string]map[*websocket.Conn]bool，读多写少时性能可控，且能显式控制锁粒度 - 每个房间内连接用
map[*websocket.Conn]bool而非切片，delete安全，遍历无序但无副作用 - 绝不把全局连接池或跨房间连接混在一个 map 里做广播过滤——QPS 上千时 CPU 毛刺明显
如何让广播动作和连接生命周期真正解耦
广播不能依赖连接是否“还在线”，而应依赖连接是否“可写”。常见错误是只在 defer conn.Close() 或 recover() 里清理，结果网络中断后连接残留，下次广播仍尝试写，卡死 goroutine。
关键动作必须在 readPump 中完成：
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 监听
conn.ReadMessage()返回值：收到io.EOF、websocket.CloseMessage或net.OpError时，立刻从房间 map 中delete(conn)并调用conn.Close() - 广播前对房间 map 加
RLock，遍历中对每个 conn 先调用conn.SetWriteDeadline(time.Now().Add(5 * time.Second))，再conn.WriteMessage() - 若
WriteMessage()返回 error（如websocket: close sent、i/o timeout），立即delete并Close()，不等下次广播
单连接 WriteMessage 并发不安全，怎么绕过
*websocket.Conn.WriteMessage() 不是 goroutine 安全的——这是硬限制，不是配置问题。你无法靠加锁“修复”它，只能重构调用方式。
两种可行路径：
- 为每个 conn 启一个专属
writePumpgoroutine，绑定唯一chan []byte；广播时只send到该 channel，由 pump 串行调用WriteMessage() - 若坚持同步写（如内部低流量系统），必须为每个 conn 单独配一把
sync.Mutex，且锁范围仅限该 conn 的一次WriteMessage()调用，绝不可跨 conn 共享同一把锁 - 无论哪种方式，
conn.SetWriteDeadline()必须在每次WriteMessage()前设置，超时不生效
集群部署时，广播域逻辑必须分层
单机模型跑得再稳，上 Nginx 负载均衡后，A 节点用户发的消息 B 节点用户收不到——这不是 bug，是架构事实。Redis Pub/Sub 是目前最轻量可靠的跨节点中继方案。
实操要点：
- 本地仍维护
groupMap *sync.Map（roomID → *sync.Map），负责本机连接归属和投递 - 所有节点
PUBLISH到统一频道（如ws:room:chat-a），每个节点起独立 goroutineSUBSCRIBE并转发到对应本地 room 的 write channel - Redis 连接必须带
context.WithTimeout，避免网络抖动卡死整个订阅 goroutine - 别让
SUBSCRIBEgoroutine 直接调用conn.WriteMessage()——仍要经由每个 conn 的 writePump channel，否则并发写 panic 依旧发生
最容易被忽略的是：WriteDeadline 必须每次写前重设，不是设一次就永久生效；还有，断开清理必须发生在 readPump 的 error 分支里，而不是 defer 或信号捕获中——后者根本抓不到网络闪断这类瞬时错误。
