gorilla/websocket 是唯一现实选择，因其封装连接状态、自动处理心跳与分片、要求显式关闭连接，而标准库 net/http 缺乏帧读写等基础能力，易致 1006 错误或 goroutine 泄漏。
为什么 gorilla/websocket 是唯一现实选择
标准库 net/http 虽然能处理 WebSocket 升级，但不提供帧读写、心跳、连接生命周期管理等基础能力。直接用它写聊天室，三天内大概率会遇到 websocket: close 1006 (abnormal closure) 或 goroutine 泄漏。而 gorilla/websocket 是事实标准——它把连接状态封装进 *websocket.Conn，自动处理 ping/pong、分片、缓冲区复用，并且明确要求你调用 conn.Close()，否则连接永远卡在 ESTABLISHED 状态。
实操建议：
- 别碰
gobwas/ws或自己解析 Upgrade Header：它们缺少连接池和并发安全的读写锁，多人同时发消息时容易 panic - 初始化连接必须用
upgrader.Upgrade()，不能只写http.ResponseWriter.WriteHeader(101)—— 否则浏览器收不到 Sec-WebSocket-Accept 响应头，报错Error during WebSocket handshake: Unexpected response code: 200 - 每个连接必须单独起 goroutine 调用
conn.ReadMessage()，因为它是阻塞的；写操作要用conn.WriteMessage()配合互斥锁或带缓冲 channel，避免多个 goroutine 并发写导致write tcp: use of closed network connection
如何安全地广播消息而不阻塞新连接
聊天室最典型的性能陷阱是：用一个全局 map[*websocket.Conn]bool 存所有连接，然后每次发消息都遍历 map 调用 conn.WriteMessage()。这会导致两个问题：一是某个慢客户端（比如网络抖动）会让整个广播卡住；二是遍历时新增连接可能被跳过，或者遍历中连接断开引发 panic。
正确做法是把「广播」变成异步事件流：
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 用一个无缓冲 channel
broadcast接收要发的消息，类型为struct{ data []byte } - 启动一个单独 goroutine 持续从
broadcast读取消息，再逐个向注册的连接发送——但发送前先用conn.SetWriteDeadline()设 5 秒超时，超时就delete连接并关闭 - 每个连接的读 goroutine 收到消息后，不是直接写，而是发到
broadcastchannel；这样读写完全解耦，新连接不会被正在广播的慢连接拖住 - 注意：
broadcastchannel 本身不能无限堆积，需设小缓冲（如 64），满时丢弃旧消息，否则 OOM
为什么不能用 sync.Map 存在线用户
sync.Map 看似适合高并发存连接，但它不支持原子性遍历——你无法在不锁整个 map 的前提下安全地 copy keys 或 range 值。聊天室需要频繁做两件事：广播时遍历所有连接、用户退出时清理指定连接。如果一边广播一边删连接，sync.Map.Range() 可能漏掉刚加入的连接，也可能对已关闭的 *websocket.Conn 调用 WriteMessage()，触发 panic: write tcp: use of closed network connection。
更稳的做法是：
- 用普通
map[*websocket.Conn]bool+sync.RWMutex：读广播时用RLock()，写增删时用Lock() - 连接注册和注销必须成对：在
upgrader.Upgrade()成功后立刻mu.Lock(); clients[conn] = true; mu.Unlock()，并在 defer 中确保mu.Lock(); delete(clients, conn); mu.Unlock() - 广播 goroutine 内部不要 hold 读锁太久——先
mu.RLock()拷贝一份连接切片，再RUnlock()，最后遍历切片发消息；否则新用户连不上
客户端断连时，服务端怎么及时感知并清理
浏览器关标签、手机切后台、WiFi 切 4G，都会让 WebSocket 连接静默断开，但 TCP 层可能几小时才发 FIN。服务端若不主动探测，clients map 里就堆满僵尸连接，内存涨、广播变慢、甚至触发系统文件描述符限制。
必须启用心跳机制：
- 服务端每 30 秒调一次
conn.WriteMessage(websocket.PingMessage, nil)；客户端收到 ping 必须回 pong（gorilla/websocket默认自动处理） - 设置读超时：
conn.SetReadDeadline(time.Now().Add(60 * time.Second))，并在每次ReadMessage()前重置；超时就 break 循环，执行清理 - 关键细节：ping 必须由服务端发起，不能依赖客户端定时发；因为有些客户端（如微信内置浏览器）会静默丢弃 ping 帧
- 不要用
http.DetectContentType()或类似逻辑判断连接是否存活——它没用，TCP 连接状态不可靠
真正难的是超时精度和资源平衡：心跳太密（90 秒）导致僵尸连接堆积。30 秒 ping + 60 秒 read deadline 是经过压测验证的合理组合。
