必须用gorilla/websocket而非标准库net/http，因其仅支持HTTP升级响应，帧解析、心跳、掩码、碎片重组等需手动实现且极易出错；Upgrader.Upgrade()须在handler内调用并接管TCP连接生命周期，读写必须分离goroutine并配专属写channel。
直接用 gorilla/websocket，别碰标准库 net/http 的原生能力——它只管 HTTP 升级响应，帧解析、心跳、掩码、碎片重组全得手写，错一个字节（比如 Sec-WebSocket-Accept 算错）连接就静默失败。
为什么 Upgrader.Upgrade() 必须在 handler 里调，不能注册完路径就完事
Upgrader.Upgrade() 不是“返回一个连接”，而是接管底层 TCP 连接生命周期。HTTP handler 返回后，http.ResponseWriter 就失效了，但 WebSocket 需要持续读写；如果只注册 http.HandleFunc("/ws", ...) 却不在函数体内调 upgrader.Upgrade(w, r, nil)，浏览器会报 ERR_CONNECTION_CLOSED 或服务端抛 websocket: bad handshake。
- 必须在 handler 函数内调用
upgrader.Upgrade()，且调用前不能往w写任何东西（包括空格、换行），否则触发http: multiple response.WriteHeader calls - 升级成功后立即
defer conn.Close()是错的——这会让连接在 handler 结束时关闭，而 handler 是短生命周期的；真正该 defer 的是清理逻辑（如从 clients map 中移除），连接本身要交给长期 goroutine 管理 - 别用
gin或echo的中间件“封装” upgrade：它们只是转发请求，conn 生命周期仍由你负责，套框架反而容易漏掉 goroutine 托管
ReadMessage 和 WriteMessage 为什么不能混在同一个 goroutine 里连续调
conn.ReadMessage() 和 conn.WriteMessage() 都不是并发安全的，但问题不止于“panic”。更常见的是：前端发一条消息，后端收到空字符串或乱码；或者某次 WriteMessage() 后连接静默断开，日志里只有 websocket: close sent。
-
ReadMessage()自动处理 FIN、opcode、掩码解密、碎片重组；用conn.Read()手动读字节流极易因边界判断出错 - 多个 goroutine 同时调
WriteMessage()会 panic：concurrent write to connection；即使只一个 goroutine，先ReadMessage()再紧跟着WriteMessage()，也可能因内部缓冲区状态冲突导致阻塞或丢帧 - 正确做法：读用一个 goroutine 循环调
ReadMessage()；写走独立 goroutine + 带缓冲 channel（建议send chan []byte，buffer size 设为 32）；广播时只往每个 client 的 send channel 发，不直连conn.WriteMessage()
SetReadDeadline 和 SetWriteDeadline 怎么设才不卡死 goroutine
没设 deadline 的连接，客户端拔网线后 ReadMessage() 会永久阻塞，goroutine 泄漏，Linux 下很快 hit ulimit -n；WriteMessage() 在对端断连后也会无限挂起，拖垮整个广播循环。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 升级成功后立刻调
conn.SetReadDeadline(time.Now().Add(30 * time.Second))，每次成功ReadMessage()后重置 - 在
PongHandler里只做conn.SetReadDeadline()，别加日志、DB 查询等耗时操作——它跑在读 goroutine 里，会阻塞后续消息 - 每次调
WriteMessage()前必须设conn.SetWriteDeadline(time.Now().Add(5 * time.Second))；遇到websocket.ErrCloseSent或io.EOF，立刻conn.Close()并从 clients map 移除 - 别依赖 TCP keepalive：Nginx 默认
proxy_read_timeout 60s，只要服务端 60 秒没发数据，它就静默 kill 连接；服务端得主动每 25 秒发一次websocket.PingMessage
clients map 为什么要用 sync.RWMutex 而不是 sync.Map
广播场景下，clients 要被频繁遍历（读多），偶尔增删（写少）。sync.Map 不支持安全遍历，且它的原子操作开销在 map size 较小时反而更高；原生 map 并发读写直接 panic。
- 用
sync.RWMutex：广播协程遍历时用Rlock()/RUnlock()，允许多个 reader 并发；注册/注销连接时用Lock()/Unlock()排他 - 别图省事把
*websocket.Conn存进全局 map 后就不管了——每个 conn 必须绑定专属 writer goroutine，否则写 channel 关闭后，goroutine 还卡在range c.send里等消息 - 连接关闭时，除了
conn.Close()，还得确保 writer goroutine 退出（channel 关闭 + range 结束），再从 clients map 中删掉 key，否则内存泄漏
最易被忽略的一点：所有超时控制（read/write deadline、ping 间隔、pong 响应窗口）必须对齐 Nginx 或负载均衡器的 timeout 设置，否则应用层心跳再勤快，网关一掐连接就断。
