Go标准库无原生WebSocket实现，生产环境须用第三方库；gorilla/websocket是事实标准，nhooyr.io/websocket适合高并发场景，gobwas/ws仅适用于底层定制开发。
go 标准库没有原生 websocket 实现——这是常见误解的起点。官方 net/http 仅提供底层 http 升级能力，不包含 websocket 协议解析、帧处理、掩码校验、ping/pong 管理等逻辑。所谓“标准库 websocket”并不存在，所有生产级 go websocket 服务都依赖第三方库。
gorilla/websocket 是事实标准，不是可选替代品
如果你看到项目里用 net/http “手写 upgrade”，那大概率是误入歧途：要自己实现 RFC 6455 的帧解包、控制帧分发、连接状态机、缓冲区管理、错误恢复……实际成本远高于引入一个成熟库。
-
gorilla/websocket提供完整协议栈，通过Upgrader.Upgrade()封装了全部握手与初始化逻辑 - 它默认禁用压缩，但支持
EnableCompression: true和CompressionLevel精细控制，避免小消息被 zlib 拖慢 -
ReadBufferSize/WriteBufferSize可设为 0，复用http.Server的缓冲区，减少内存碎片 - 它的
CheckOrigin回调是跨域防护的第一道防线，不填或直接返回true等同于开放 CSRF 攻击面
nhooyr.io/websocket 更适合 10 万+ 连接场景
当单机连接数突破 5 万，GC 压力和内存占用会成为 gorilla 的瓶颈：它为每个 *Conn 分配独立读写缓冲区（默认各 4KB），实测单连接常驻内存约 2–3KB；而 nhooyr.io/websocket 使用零拷贝 + io.ReadWriter 复用，压到 0.5–1KB，GC 频率下降一个数量级。
- 升级调用是
websocket.Accept(w, r, &websocket.AcceptOptions{...})，强制传context.Context，超时控制更自然 - 默认开启 permessage-deflate，但只对 >1KB 消息压缩，避免小消息徒增 CPU 开销
- 不支持全局关闭心跳，
Ping必须手动触发，Pong自动响应——这反而利于调试连接僵死问题 - 没有
Subprotocols字段，需在AcceptOptions中显式传入切片，协议协商更透明
别碰 gobwas/ws，除非你已在 epoll 层写代码
gobwas/ws 不是 gorilla 的“更快版本”，它是绕过 net/http 的裸连接处理器：不兼容 http.Handler，不处理 TLS 握手、HTTP 头解析、upgrade 请求校验，连 400 Bad Request 都得自己写。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 升级后返回的是
ws.Conn，没有ReadMessage()/WriteMessage()，只有ReadFrame()/WriteFrame() - 无内置 ping/pong，必须手动发送
ControlFrame并处理CloseFrame状态迁移 - 压缩需自行配置
flate.Reader/Writer，且不校验客户端是否声明支持permessage-deflate - 社区近一年无实质更新，出问题只能翻
frame.go和conn.go，不适合业务系统快速迭代
真正卡住性能的往往不是库本身，而是连接生命周期管理方式：gorilla 的 Conn 是有状态对象，不能复用；nhooyr 的 Conn 更接近无状态句柄；而 gobwas 的 Conn 几乎就是文件描述符包装。选哪个，取决于你愿不愿意为省下的那几百 KB 内存，多写三倍的错误处理和心跳逻辑。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
