不能直接用 map[string]*websocket.Conn 存连接，因为 Go 的 map 非并发安全，多 goroutine 读写会 panic；需用 sync.RWMutex 或封装 sync.Map，并配合连接状态检查与发送队列确保广播安全。
为什么不能直接用 map[string]*websocket.Conn 存连接
因为 Go 的 map 不是并发安全的——只要两个 goroutine 同时读写同一个 map（比如一个在广播消息，一个在用户断开时删连接），程序大概率 panic，报错信息通常是：fatal error: concurrent map read and map write。
常见错误场景：用户上线/下线、心跳检测、消息广播都各自跑在不同 goroutine 里，但共用一个全局 map，没加锁就直接 delete 或 range。
实操建议：
- 用
sync.RWMutex包一层，读多写少时性能比sync.Mutex更好 - 不要把
*websocket.Conn直接塞进 map 当 value —— 它本身不是线程安全的，后续调用WriteMessage仍需单独加锁或用 channel 控制写入 - 更稳妥的做法是用
sync.Map，但它不支持遍历，广播消息时还得额外维护一个 key 列表
如何安全地广播消息给所有在线用户
广播不是简单地 for range map 然后发消息。WebSocket 连接随时可能断开，而 map 里的指针不会自动失效；强行调用 WriteMessage 会触发 write tcp: use of closed network connection 错误，甚至导致 goroutine 泄漏。
立即学习“go语言免费学习笔记（深入）”；
实操建议：
- 每次写之前先检查连接状态：
conn.WriteMessage(websocket.TextMessage, msg)要用defer或recover捕获 panic，或提前调用conn.WriteDeadline+conn.SetWriteDeadline配合超时控制 - 推荐用“发送队列”模式：每个连接绑定一个 goroutine 和专属
chan []byte，主逻辑只往 chan 发，由该 goroutine 负责重试和清理 - 广播前先用
RWMutex.RLock()读取当前所有连接，再逐个发；发完立刻RLock解锁，避免阻塞其他读操作
sync.Map 在聊天室里到底该不该用
sync.Map 看起来省事，但它隐藏了两个关键问题：无法安全遍历、value 类型擦除导致类型断言易错。
使用场景有限：适合纯增删查（如用户登录态缓存），但聊天室必须广播、必须按用户名查连接、还常要统计在线人数——这些操作都绕不开遍历或强类型操作。
实操建议：
- 如果坚持用
sync.Map，务必封装一层：type ClientMap struct { m sync.Map }，并在方法里统一做value, ok := m.Load(key); conn, ok := value.(*websocket.Conn) - 别依赖
sync.Map.Range做广播——它不保证遍历时 map 不被修改，且中间插入/删除可能导致漏发 - 小规模聊天室（map +
RWMutex更清晰可控；想省心就用现成库如gorilla/websocket官方示例里的Hub结构
用户断开时怎么从 map 里干净地删掉连接
很多人只记得在 defer 里删 map，却忘了：WebSocket 断开可能是网络闪断、客户端崩溃、Nginx 超时踢出，这些情况下 ReadMessage 可能卡住或返回 io.EOF / websocket.CloseAbnormalClosure，但 goroutine 并未退出，map 里的条目就一直挂着。
实操建议：
- 必须在
ReadMessage返回非nilerror 后才触发清理逻辑，且要确保只删一次（加atomic.Bool标记已关闭） - 删之前先调用
conn.Close()，否则底层 TCP 连接可能 linger，影响复用和监控 - 删完立即调用
RWMutex.Lock()→delete()→Unlock()，别把锁粒度扩大到整个清理流程（比如包含日志打印）
最麻烦的其实是“假在线”：连接没显式 close，但已收不到消息。得靠心跳机制识别，而心跳响应也要走同一套 map 查找+写入路径——这里最容易漏锁或重复删。
