Go标准库不支持WebSocket，需用第三方库；性能瓶颈在连接管理、并发模型和内存复用，而非协议解析；gorilla/websocket最成熟但需正确配置CheckOrigin、缓冲区大小及Ping/Pong处理器；读写应分离并用channel+sync.Pool优化。
Go 的 net/http 和标准库本身不直接支持 WebSocket 协议，必须依赖第三方实现；性能瓶颈通常不出现在协议解析层，而在于连接管理、读写并发模型和内存复用上。
为什么别自己用 net/http 手搓 WebSocket 升级逻辑
WebSocket 握手是 HTTP 协议的特殊升级流程（Upgrade: websocket），需校验 Sec-WebSocket-Key、生成响应头、切换底层连接状态。标准 http.ServeHTTP 会缓冲响应、关闭底层 conn，导致升级失败或 panic。
- 手动调用
conn.SetReadDeadline/conn.SetWriteDeadline容易漏设，引发 goroutine 泄漏 - 升级后若未立即接管
conn，http.Server可能在超时后强行关闭它 - 没有消息分帧、ping/pong 自动应答、连接心跳等基础能力，全得自己补
用 gorilla/websocket 时必须设置的三个关键配置
gorilla/websocket 是目前最成熟、压测表现最稳的 Go WebSocket 库，但默认配置不适合高并发长连接场景。
-
Upgrader.CheckOrigin = func(r *http.Request) bool { return true }—— 生产环境必须改，否则跨域请求全被拒 -
Upgrader.ReadBufferSize和Upgrader.WriteBufferSize建议设为4096或8192，避免小 buffer 频繁 alloc/free - 连接建立后立刻调用
conn.SetPingHandler并启用conn.SetPongHandler，否则客户端 ping 超时会静默断连
读写分离 + 无锁 channel 是降低 goroutine 开销的核心
每个连接起两个长期 goroutine（一个读，一个写）是常见做法，但写操作若直接调用 conn.WriteMessage，在高并发推送时会阻塞并拖慢整个连接。
立即学习“go语言免费学习笔记（深入）”；
- 用带缓冲的
chan []byte（如make(chan []byte, 64)）做写队列，写 goroutine 循环select消费 - 读 goroutine 收到消息后，不要直接处理业务逻辑，而是发到业务 dispatcher 的统一 channel，避免阻塞读循环
- 所有
[]byte尽量复用sync.Pool，尤其是消息头、JSON 序列化结果；避免每次json.Marshal分配新 slice
gobwas/ws 和 nhooyr.io/websocket 的适用边界
gorilla/websocket 功能全、文档好，但内部有较多 interface{} 和反射开销；追求极致吞吐（如万级连接+高频广播）时可考虑更轻量的替代方案。
-
gobwas/ws：零依赖、纯字节操作，适合嵌入式或对二进制帧有定制需求的场景；但不自动处理 ping/pong，需手动轮询ws.State -
nhooyr.io/websocket：API 更现代（context-aware），默认使用io.ReadWriter接口，兼容性更好；但不支持子协议协商（Sec-WebSocket-Protocol） - 两者都不提供连接池或广播管理，这些仍需上层封装
真正卡性能的往往不是 WebSocket 协议本身，而是你如何管理连接生命周期、怎么序列化消息、是否让一次 GC 扫描几万个连接对象——这些细节比选哪个库影响更大。
