浏览器前端聊天室必须用 http 升级握手，net.listen("tcp", ":8080") 无法响应 ws:// 请求；正确路径是用 net/http + gorilla/websocket 在 /ws 路由完成 upgrade；upgrade 后禁止再操作 http.responsewriter；每个连接需独立 writepump goroutine 序列化写入；gorilla/websocket 提供帧处理、心跳等生产必需能力。
为什么不能直接用 net.Listen("tcp", ":8080") 写浏览器前端聊天室
因为浏览器的 WebSocket 连接必须经过 HTTP Upgrade 握手，裸 TCP 服务根本不会响应 ws:// 请求——你打开控制台只会看到 net::ERR_CONNECTION_REFUSED。这不是端口没开，是协议层压根不认。
- 浏览器只支持通过 HTTP 协议发起 WebSocket 升级，
net包监听的纯 TCP 端口无法完成 RFC 6455 所需的握手流程 - 哪怕你用命令行
telnet能连上，前端也永远连不上；这是架构选择错误，不是配置问题 - 正确路径是：用
net/http启一个 HTTP 服务，注册/ws路由，再用gorilla/websocket在该路由里做 Upgrade
upgrader.Upgrade() 报 http: multiple response.WriteHeader calls 怎么办
这个 panic 几乎每个新手都会撞上，根源在于：Upgrade 本身已向客户端发了完整的 HTTP 响应（状态码 101 + 头），你若在它前后调用 w.Write()、http.Error() 或任何写响应操作，就等于重复写头。
- 升级前绝对不要碰
http.ResponseWriter，包括w.WriteHeader()、w.Write()、fmt.Fprint(w, ...) - 升级失败时直接
return，别试图返回 HTML 错误页；升级成功后，w和r就失效了，后续通信全靠返回的*websocket.Conn - 正确写法：
conn, err := upgrader.Upgrade(w, r, nil)→if err != nil { return }→ 后续只调conn.ReadMessage()和conn.WriteMessage()
如何安全广播消息而不触发 concurrent write to websocket connection
*websocket.Conn 的读写方法不是 goroutine 安全的。多个地方（比如系统通知、群聊转发、私聊回执）同时往同一个连接写，必然 panic。
- 不能在广播循环里直接对每个
client调client.WriteMessage()；必须让每个连接的写入串行化 - 推荐做法：为每个连接启动独立的
writePumpgoroutine，它从专属 channel 读消息并顺序写出；广播协程只负责把消息推给所有 client 的 channel - 避免用
sync.Map存 clients——注册/注销频率低，用channel控制变更更清晰，还能天然防止并发 map 修改 panic
为什么必须用 gorilla/websocket，而不是硬啃标准库
Go 标准库 net/http 只提供 Upgrade 握手能力，但 WebSocket 协议远不止握手：帧解析、掩码解包、PING/PONG 心跳、分片重组、控制帧校验……这些全得自己实现。
立即学习“go语言免费学习笔记（深入）”；
- 不用
gorilla/websocket的后果：连接一断、浏览器重连、发个长消息，就大概率出现websocket: bad write message type或i/o timeout，且无法区分是协议 bug 还是业务逻辑错 -
gorilla/websocket提供SetReadDeadline、WriteJSON、自动心跳等生产必需能力，还默认禁用并发写——逼你设计正确的写入模型 - 它不帮你加锁，但给你留出明确的扩展点；而自己手撸协议，99% 的时间都在修底层崩溃，不是写聊天逻辑
