用net/http而非直接写TCP服务，因HTTP+WebSocket方案成熟高效：net/http处理握手路由，gorilla/websocket封装协议升级、心跳等；需用sync.RWMutex保护用户map、为每个连接配带超时和生命周期控制的独立写goroutine，并配置反向代理支持WebSocket。
为什么用 net/http 而不是直接写 TCP 服务？
新手常以为聊天室必须手撸 TCP 连接管理，其实 HTTP + WebSocket 就够用，且生态成熟。Go 标准库的 net/http 足以承载握手和路由，真正通信交给 gorilla/websocket（事实标准）。自己用 net.Listen("tcp", ...) 做长连接，反而要重复处理协议升级、心跳、断连重试——这些 gorilla/websocket 都封装好了。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 先用
http.HandleFunc("/ws", wsHandler)暴露一个 WebSocket 端点，别急着写ListenAndServeTLS或自定义 listener - 客户端用浏览器原生
WebSocket对象直连ws://localhost:8080/ws，验证通路比写 CLI 客户端快得多 - 别在
Upgrade前做耗时操作（比如查数据库），gorilla/websocket的Upgrader.Upgrade()必须在 60 秒内完成，否则浏览器会报ERR_CONNECTION_CLOSED
map[string]*websocket.Conn 为什么不能直接当在线用户表用？
并发读写 map 会 panic："fatal error: concurrent map read and map write"。聊天室里用户上线、下线、广播消息全是并发触发，必须加锁。但别用全局 sync.Mutex 锁整个 map——广播时所有 goroutine 都要等锁，性能卡死。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
sync.RWMutex，读多写少场景下，多个ReadLock可并行，只有WriteLock（如用户退出）才互斥 - 用户连接对象别只存
*websocket.Conn，至少附带id string和joinTime time.Time，否则广播时连谁发了什么消息都追溯不了 - 不要在
conn.WriteMessage()失败后直接deletemap 中的项——得先用conn.Close()，再删，否则残留的已关闭连接会阻塞后续写入
如何安全地广播消息而不崩掉某个慢连接？
一个用户网络卡顿或客户端没读消息，conn.WriteMessage() 会阻塞，进而拖慢整个广播循环。更糟的是，如果用 for-range 遍历连接 map 并同步写，一个卡住就导致其他所有人收不到新消息。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 给每个连接配独立的写 goroutine：
go func(c *websocket.Conn) { c.WriteMessage(...) }(conn)，但必须配合done chan struct{}控制生命周期，否则 goroutine 泄漏 - 用
conn.SetWriteDeadline()，比如time.Now().Add(5 * time.Second)，超时就跳过该连接，避免无限等待 - 广播前先检查
conn.IsClosed()（需用gorilla/websocketv1.5+），老版本只能靠WriteMessage返回 error 判断
为什么本地测试通，部署到服务器就频繁断连？
常见原因是反向代理（Nginx / Caddy）默认不转发 WebSocket 升级头，或者设置了短超时。浏览器控制台看到 WebSocket connection to 'ws://...' failed，八成是代理层问题，不是 Go 代码错。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- Nginx 配置必须包含：
proxy_http_version 1.1;、proxy_set_header Upgrade $http_upgrade;、proxy_set_header Connection "upgrade"; - 禁用 Nginx 的
proxy_read_timeout（默认 60 秒），设为 0 或足够大，否则空闲连接会被代理主动断开 - 用
curl -i -N -H "Connection: Upgrade" -H "Upgrade: websocket" http://your-server/ws手动测升级响应头，比刷网页更快定位代理问题
真正的难点不在 Goroutine 怎么起，而在连接生命周期的每个环节——从 Upgrade 成功那一刻起，到收到 close frame、清理 map、关闭底层 TCP 连接——漏掉任意一环，都会让连接堆积或消息丢失。细节多，但每一步都有明确检查方式，别信“应该没问题”。
