靠默认“一连接一goroutine+gorilla/websocket”模式无法支撑百万连接，因内存爆满、goroutine调度失衡、文件描述符耗尽；可行路径是系统调优+异步I/O+库级缓冲复用。
直接说结论：靠默认的“一连接一 goroutine + gorilla/websocket”模式，根本撑不住百万连接——内存爆掉、goroutine 调度失衡、系统文件描述符耗尽，三者必中其一。真正可行的路径是：系统调优打底 + 异步 I/O 替代阻塞读写 + 库级缓冲复用。
为什么 gorilla/websocket 在百万连接下内存暴涨
它为每个连接分配独立的读写缓冲区（默认各 4KB），100 万连接就是 ~8GB 内存；更关键的是，它的 ReadMessage/WriteMessage 是同步阻塞调用，必须配一个 goroutine 等着数据就绪，导致百万 goroutine 常驻，调度开销远超业务逻辑本身。
实操建议：
- 别在
for循环里直接go handleConn(conn)启动 goroutine 处理每个连接 - 避免调用
conn.SetReadDeadline配合ReadMessage，这会强制维持 goroutine 生命周期 - 如果必须用
gorilla/websocket，至少把WriteBufferPool设为共享池，但读缓冲仍无法复用
用 gobwas/ws 替换库能省多少内存
gobwas/ws 的核心优势是「连接间缓冲区复用」：它不为每个连接 malloc 新 buffer，而是从全局池里借，用完归还。实测 100 万连接下，内存占用从 gorilla 的 3.2GB 降到 860MB 左右，且 goroutine 数量稳定在几百个而非百万级。
关键代码差异：
// gorilla：缓冲区绑定到 conn 实例 conn, _ := upgrader.Upgrade(w, r, nil) conn.SetReadBufferSize(4096) // 每个 conn 独占一份 <p>// gobwas：显式传入 buffer，可复用 buf := getBuf() // 从 sync.Pool 获取 conn, <em>, </em>, err := ws.UpgradeHTTP(r, w) _, err = ws.ReadFrame(conn, buf) // buf 用完后 put 回 pool
注意：gobwas/ws 不兼容 gorilla 的 API，需重写消息收发逻辑，但换来的是确定性的内存上限。
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
Linux 系统参数不调，Go 代码再优也起不来
百万连接意味着至少 100 万个 socket 文件描述符，而 Linux 默认 ulimit -n 是 1024。没调这个，accept 直接返回 EMFILE 错误，新连接全被拒。
必须调整的几项：
-
ulimit -n 1048576（临时）或在/etc/security/limits.conf中设* soft nofile 1048576 -
sysctl -w net.netfilter.nf_conntrack_max=2621440（防止 conntrack 表溢出丢包） -
sysctl -w net.ipv4.ip_local_port_range="1024 65535"（扩大可用端口范围）
Go 服务启动前，务必用 syscall.Getrlimit(syscall.RLIMIT_NOFILE, &rLimit) 主动检查当前限制，不达标就 panic，别等连接堆到 99 万才失败。
epoll/kqueue 事件驱动比 goroutine 更适合海量连接
传统模型是“来一个连接，启一个 goroutine 死等读”，而事件驱动模型是“一个 goroutine 管 10 万连接，只在有数据可读/可写时才处理”。后者把 goroutine 数量压到百级，彻底避开调度瓶颈。
Go 标准库不暴露 epoll，所以得靠封装：
- 用
golang.org/x/sys/unix手写 epoll 循环（参考3_optimize_ws_goroutines/epoll.go） - 监听
EPOLLIN | EPOLLET（边缘触发），避免重复唤醒 - 把
net.Conn的FD()注册进 epoll，而不是对*websocket.Conn操作
真正的难点不在 epoll 本身，而在如何把 WebSocket 帧解析逻辑安全地嵌入事件循环——帧头长度可变、需要粘包处理、错误时要能快速清理 fd。这部分容错设计，比选库还关键。
