如何在 Go 中使用 x/net/websocket 与标准库 WebSocket 的对比-Golang-PHP中文网

golang.org/x/net/websocket已弃用，不支持rfc 6455完整特性，易致握手失败、空闲断连和安全风险；生产环境应选用gorilla/websocket（5k连接内）或nhooyr.io/websocket（10w+连接）。

如何在 go 中使用 x/net/websocket 与标准库 websocket 的对比

golang.org/x/net/websocket 已弃用，不能用于新项目，也不具备与现代 WebSocket 服务端（如 Spring WebFlux、SockJS、nhooyr.io/websocket）可靠握手的能力。

你看到的“标准库 WebSocket”根本不存在——net/http 只提供 Upgrade 原语，不实现 RFC 6455 协议栈。所谓“标准库支持”是常见误传。

`golang.org/x/net/websocket` 为什么必须淘汰

它在 2015 年进入维护模式，2021 年起官方明确标注为 deprecated
不支持子协议协商（Sec-WebSocket-Protocol），和多数前端框架握手失败
缺少 Ping/Pong 控制帧处理，连接空闲时易被中间代理断开
没有 context.Context 集成，超时、取消、trace 都得手动 hack
实测在 500+ 并发下，upgrade 失败率超 30%，不是性能问题，是协议解析缺失

如果你的代码里还 import "golang.org/x/net/websocket"，第一件事是删掉它，而不是调优。

`gorilla/websocket` 是当前事实标准，但默认配置很危险

它不是“可选替代”，而是生产环境唯一合理起点。但直接用默认参数上线，等于裸奔：

Upgrader.CheckOrigin 不设回调或写死 return true → 开放 CSRF 攻击面
ReadBufferSize/WriteBufferSize 为 0 且没复用 http.Server 缓冲区 → 小消息频繁 alloc，GC 暴涨
EnableCompression: true 却没配 CompressionLevel → 100B 消息也被 zlib 压缩，CPU 白耗
忘记设 HandshakeTimeout 和 WriteDeadline → 客户端异常断连后，conn.ReadMessage() 卡住 goroutine，堆积泄漏

典型调优写法：

WebSocket 8.18.2

WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。

下载

upgrader := websocket.Upgrader{
    CheckOrigin: func(r *http.Request) bool {
        return r.Header.Get("Origin") == "https://myapp.com"
    },
    ReadBufferSize:  64 * 1024,
    WriteBufferSize: 64 * 1024,
    EnableCompression: true,
    CompressionLevel:  zlib.BestSpeed,
    HandshakeTimeout: 5 * time.Second,
}