核心是用注册/注销通道+单hub goroutine统一管理连接，配readPump/writePump双协程分离读写，加心跳检测与错误清理机制，确保1000连接24小时稳定。
用 Golang 实现并发 WebSocket 多客户端消息推送，核心不是“能不能”，而是“怎么组织 goroutine 和 channel 才不丢消息、不 panic、不泄漏连接”。gorilla/websocket 本身不管理连接生命周期，所有并发安全、广播逻辑、异常清理都得你亲手搭。
为什么不能直接用 map[*websocket.Conn]bool 存客户端？
并发读写原生 map 会触发 fatal error: concurrent map read and map write。哪怕只是遍历广播时另一个 goroutine 正在删连接，也会崩。
- 必须用
sync.RWMutex包裹读写操作，或改用sync.Map（但注意：它不支持遍历，广播时仍需额外维护 slice 或 channel） - 更推荐方案：用注册/注销通道 + 单独的 hub goroutine 统一管理，所有增删都在一个 goroutine 内完成，天然线程安全
- 示例中常见错误：在
conn.ReadMessage()的 for 循环里直接delete(clients, conn)—— 这是并发写 map 的高危操作
conn.ReadMessage() 和 conn.WriteMessage() 必须分离到不同 goroutine
WebSocket 连接是全双工，但阻塞式读写会互相拖慢。比如客户端发了一大段消息卡住读协程，就无法响应 pong 或发送广播，最终触发超时断连。
- 每个连接至少启动两个 goroutine：
readPump（只读、转发消息到 broadcast channel）和writePump（只写、监听该 client 的sendchannel） -
writePump中务必用select+default或带超时的send，防止 client 不读消息导致 send channel 堵死，进而卡住整个 hub - 别在
writePump里调conn.SetWriteDeadline()后无脑WriteMessage()—— 若网络抖动，会 panic；应捕获websocket.IsCloseError(err)和io.EOF并主动退出
心跳检测不是可选项，而是连接存活的唯一可信依据
HTTP 升级后的 WebSocket 连接，底层 TCP 可能静默断开（如 NAT 超时、中间代理 kill 空闲连接），而 Go 代码完全感知不到，直到下次 WriteMessage() 才报错 —— 此时已积压多条消息。
立即学习“go语言免费学习笔记（深入）”；
- 必须启用
conn.SetPingHandler()，并在writePump中用time.Ticker定期发websocket.PingMessage - 服务端收到 ping 后自动回 pong，但你要在
readPump中设置conn.SetReadDeadline()，超时未收消息即视为离线 - 别依赖前端发心跳 —— 客户端页面崩溃、标签页休眠、手机锁屏都会中断 JS 执行；心跳必须由服务端主动发起并监控响应
广播消息前，一定要检查 conn.WriteMessage() 返回值
看似简单的 for range clients { conn.WriteMessage(...) }，实际极易因某个 client 连接已断却未及时清理，导致 panic 或阻塞。
- 每次
WriteMessage()后必须判断err，对websocket.IsUnexpectedCloseError(err)、io.ErrClosed、net.ErrClosed等做清理：关闭sendchannel、从管理器移除、conn.Close() - 避免在广播循环中直接
deletemap —— 应发信号给 hub goroutine 异步处理，否则可能和注册逻辑冲突 - 如果用
sync.Map，记得用LoadAndDelete()或先Load()再显式Delete()，不要边遍历边删
真正难的从来不是写出能跑通的 demo，而是让 1000 个连接同时在线 24 小时不泄漏内存、不堆积 goroutine、不误杀活跃连接。每一条连接的注册、心跳、读写、清理路径，都得有明确的归属 goroutine 和退出机制 —— 没有银弹，只有层层设防。
