gorilla/websocket是go生态websocket服务端的事实标准，不可替代；标准库net/http不提供帧处理能力，手动实现握手易出错，upgrade()已封装完整逻辑，且readmessage/writemessage需读写分离goroutine保障并发安全。
gorilla/websocket 是 Go 生态中 WebSocket 服务端的事实标准，不是“可选库”，而是唯一合理选择。标准库 net/http 不提供 WebSocket 帧处理能力，硬写握手和帧解析极易触发 websocket: bad handshake、unexpected EOF 或 concurrent write to connection 等 panic。
为什么不能手动写 HTTP 101 响应？
浏览器发起 WebSocket 握手时，要求服务端返回精确的响应头：Upgrade: websocket、Connection: Upgrade、Sec-WebSocket-Accept。漏掉任一字段或值计算错误（比如 Sec-WebSocket-Accept 没按 RFC 6455 规则 base64(sha1(key + "258EAFA5-E914-47DA-95CA-C5AB0DC85B11"))），浏览器就会报 WebSocket connection to 'xxx' failed。
- 你无法用
http.ResponseWriter.WriteHeader(101)+w.Write()安全拼出合法响应 -
Upgrader.Upgrade()内部已封装完整握手逻辑，包括 Origin 校验、key 生成、header 写入和连接劫持（hijack） - 若在
Upgrade()后还往w写内容，会触发http: response.WriteHeader on hijacked connection
如何避免 ReadMessage/WriteMessage 并发 panic？
*websocket.Conn 的读方法（如 ReadMessage）和写方法（如 WriteMessage）各自线程安全，但读写之间不互斥。两个 goroutine 同时调用 ReadMessage 和 WriteMessage 不会 panic；但多个 goroutine 同时调 WriteMessage 会直接 panic： concurrent write to connection。
- 每个连接必须起两个独立 goroutine：一个只读（
for { conn.ReadMessage() }），一个只写（for { msg := ） - 禁止在读 goroutine 中直接调
conn.WriteMessage()，尤其当写逻辑含 DB 查询或 HTTP 调用 - 写通道（
writeChan）建议设缓冲区，如make(chan []byte, 32)，防止广播时阻塞主逻辑 - 务必在写 goroutine 中捕获 error，遇到
websocket.ErrCloseSent、io.EOF或net.ErrClosed时退出并清理连接
超时设置为什么必须显式调用 SetReadDeadline/SetWriteDeadline？
ReadMessage 和 WriteMessage 默认无限期阻塞。网络抖动、客户端断电、NAT 超时等场景下，goroutine 会长时间卡在 [IO wait] 状态，导致 goroutine 泄漏、内存上涨、连接堆积。
-
SetReadDeadline必须在每次ReadMessage前设置（不能只设一次），否则超时逻辑不生效 -
SetWriteDeadline同理，建议设为time.Now().Add(10 * time.Second)，比读超时略短 - 不要用
time.After包裹ReadMessage—— 这只是中断 select，底层连接仍处于阻塞读状态 - 反向代理（如 Nginx）需配置
proxy_set_header Upgrade $http_upgrade;和proxy_set_header Connection "upgrade";，否则 Upgrade 头被吃掉，握手失败
CheckOrigin 和连接管理最容易被忽略的点
Upgrader.CheckOrigin 默认返回 false，所有跨域请求都会被拒并返回 403。开发时设为 func(r *http.Request) bool { return true } 可绕过，但这只是临时手段。
- 上线前必须改为白名单校验，例如
return r.Header.Get("Origin") == "https://myapp.com" - 别用普通
map[string]*websocket.Conn存连接 —— 并发读写 map 会 panic，改用sync.Map或带RWMutex的结构体 - 连接断开时仅
defer conn.Close()不够：它只发 close frame，资源释放依赖对方响应或超时；需配合心跳（SetPingHandler）+ 主动清理逻辑 - 广播消息前，先检查
conn.IsClosed()（v1.5.0+ 支持），或更稳妥地：err := conn.WriteMessage(...); if err != nil { removeConnFromPool() }
真实线上环境里，问题往往不出在“怎么连上”，而在于“连上后怎么不死、不卡、不丢、不炸”。超时控制、读写分离、Origin 校验粒度、连接生命周期清理——这些细节没做对，服务跑不过三天。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
