不能直接用普通 map 存储长连接状态，因为 Go 中 map 非并发安全，多 goroutine 读写会触发 fatal error: concurrent map writes；Gin 每个请求（含 WebSocket）运行在独立 goroutine，连接注册、心跳、断开并发发生时必然崩溃。
为什么不能直接用普通 map 存储长连接状态
因为 map 在 Go 中不是并发安全的，多个 goroutine 同时读写会触发 panic： fatal error: concurrent map writes。Gin 处理每个 HTTP 请求（包括 WebSocket 升级后的长连接）都运行在独立 goroutine 中，一旦多个连接同时注册、心跳更新或断开，普通 map 必然崩溃。
sync.Map 的适用边界和真实代价
sync.Map 确实能避免 panic，但它不是万能解药——它的设计目标是“读多写少”，写操作（Store）比读（Load）慢一个数量级，且不支持遍历或 len() 直接获取大小。长连接场景中，如果频繁更新连接元数据（如最后心跳时间、用户 ID、权限变更），sync.Map 可能成为瓶颈。
- ✅ 适合：连接 ID → 连接对象（
*websocket.Conn）的简单映射，写仅发生在连接建立/关闭时 - ⚠️ 谨慎：需要每秒多次更新字段（如实时统计流量、延迟）的场景，改用
sync.RWMutex+ 普通map更可控 - ❌ 不适合：需按活跃时间排序、批量清理超时连接——
sync.Map无法迭代，必须额外维护切片或定时器
实际存储结构建议：连接 ID + 元数据分离
别把所有东西塞进 sync.Map。推荐分层设计：
- 主存储用
sync.Map存connectionID→*websocket.Conn，保证连接句柄可安全读取 - 元数据（用户 ID、角色、心跳时间）单独存在另一个
sync.Map或带锁结构里，按需更新 - 连接关闭时，务必调用
Delete清理，否则内存泄漏——sync.Map不会自动回收已关闭的*websocket.Conn
示例关键代码：
var connMap sync.Map // connectionID → *websocket.Conn
var metaMap sync.Map // connectionID → struct{UserID string; LastPing time.Time}
// 升级后存入
connMap.Store(connID, conn)
metaMap.Store(connID, struct{...}{UserID: "u123", LastPing: time.Now()})
// 心跳更新元数据（非连接本身）
metaMap.Store(connID, struct{...}{UserID: "u123", LastPing: time.Now()})
// 关闭前清理
connMap.Delete(connID)
metaMap.Delete(connID)
容易被忽略的资源泄漏点
WebSocket 连接对象本身持有底层网络连接和缓冲区，sync.Map 只是引用它。如果忘记在 defer 或错误路径中显式调用 conn.Close()，即使从 sync.Map 删除了键，连接仍保持打开，FD 和内存都不会释放。
更隐蔽的是：Gin 的 Context 生命周期短于长连接，千万别把 *gin.Context 存进 sync.Map —— 它会在请求结束时被回收，后续访问会导致 panic: context canceled 或空指针。
