应使用 sync.RWMutex 包裹普通 map 或 sync.Map；推荐前者，读多写少性能更优，且支持原子广播；key 用业务 ID（如 user:123），避免用 RemoteAddr；封装为 ClientManager 结构体，避免全局变量。
怎么用 map 安全存 WebSocket 连接（别直接裸用）
Go 的 map 本身不是并发安全的，一旦多个 goroutine 同时读写（比如一个在广播消息、一个在用户断开时删连接），就会触发 fatal error: concurrent map read and map write。这不是偶发问题，是必现崩溃。
常见错误是这么写：
var clients = make(map[string]*websocket.Conn)
然后在 handleMessage 或 close 回调里直接 delete(clients, userID) 或 clients[userID] = conn —— 危险。
正确做法只有两个：要么用 sync.RWMutex 包一层，要么换 sync.Map（但注意它不支持遍历，得额外维护 key 列表）。
立即学习“go语言免费学习笔记（深入）”；
- 推荐用
sync.RWMutex+ 普通map：读多写少场景下性能更好，且能原子地获取所有连接做广播 -
sync.Map适合写非常频繁、但广播需求极少的情况（比如只查单个用户状态） - 无论哪种，
map的 key 建议用业务 ID（如user:123），别用conn.RemoteAddr().String()——IP 可能重复，且 NAT 后不可靠
用户上线/下线时如何保证连接映射和在线列表一致
上线和下线逻辑必须成对、原子地更新两处状态：连接映射（用于发消息）和在线用户集合（用于查“谁在线”）。漏掉任意一步，就会出现“连接还活着但用户显示离线”，或“用户显示在线但发不了消息”。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
典型错误是把注册和注销逻辑散落在 handler 不同位置，甚至跨 goroutine 异步执行（比如 defer 里删 map，但 panic 没捕获导致漏删）。
- 上线：先生成唯一
userID（建议用 JWT payload 或登录态里的 ID），再加锁写入clientsmap 和onlineUsersmap/set；完成后才返回握手成功 - 下线：必须在
defer或conn.Close()后立即执行清理，且同一把锁保护两个操作；不要依赖客户端主动发 “logout” 消息——网络断开时它根本发不出 - 建议用
map[string]struct{}存在线用户 ID，比用bool或int更省内存、语义更清晰
怎么避免广播消息时 panic（特别是连接已关闭还在写）
WebSocket 连接可能随时因网络抖动、浏览器关闭、心跳超时而断开，但你的广播 goroutine 还在遍历 clients 并调用 conn.WriteMessage()。此时会 panic：write tcp ...: use of closed network connection。
不能靠 recover 全局兜底——这会让错误静默，且无法清理失效连接。
- 每次写之前必须检查
conn.IsClosed()（需自己实现，标准库没这个方法），或更稳妥：用conn.WriteControl()发个 ping，失败就删连接 - 更实用的做法：在写消息前加个
select配合conn.WriteDeadline，超时或失败就跳过该连接 - 广播完记得主动清理那些反复写失败的连接（比如连续 3 次失败），否则 map 越来越大，内存泄漏
为什么别用全局变量存连接映射（哪怕加了锁）
看似方便的全局 var clients map[string]*websocket.Conn，实际会让测试、模块拆分、多实例部署变得极其困难。你没法为不同业务通道（如聊天室、通知、实时协作）隔离连接，也没法按租户做连接数限制。
更大的问题是：当服务要升级或热重载时，全局状态无法优雅迁移。
- 把连接管理封装成结构体，比如
type ClientManager struct { clients map[string]*Conn; mu sync.RWMutex } - 每个业务场景（如不同 WebSocket 路由）初始化自己的
ClientManager实例 - 如果要用 Redis 做分布式连接状态同步，这个结构体还能自然扩展出
SaveToRedis()和LoadFromRedis()方法
真正麻烦的从来不是“怎么存”，而是“什么时候删、删不干净会怎样、删错地方影响谁”。连接生命周期比想象中更脆弱，状态一致性得靠设计约束，而不是靠人盯住代码。
