golang.org/x/net/websocket已弃用，不支持RFC 6455完整特性，压测结果无效；gorilla/websocket需显式调优缓冲区、超时和压缩参数才能真实反映性能。
golang.org/x/net/websocket 已被弃用，别再拿它压测
标准库 golang.org/x/net/websocket 在 2015 年就进入维护模式，2021 年起官方明确建议迁移到第三方库。它不支持 rfc 6455 的完整特性（如子协议协商、扩展帧、ping/pong 控制帧），也没有 context.context 集成，更无法通过 autobahn test suite 全部用例。任何基于它的压测结果都失去横向可比性——不是“慢”，而是“功能缺失导致连接提前断开或消息丢弃”。实测中，当并发 > 500 连接且启用子协议时，upgrade 失败率超 30%，这不是吞吐问题，是协议兼容性硬伤。
gorilla/websocket 压测关键参数必须显式调优
默认配置下压测 gorilla/websocket，吞吐量会被严重低估。它不自动复用缓冲区，也不开启压缩，更不会帮你设超时。常见错误包括：
- 没配
ReadBufferSize和WriteBufferSize，导致小消息频繁 alloc —— 实测 1KB 消息下，缓冲区从 4KB 改为 64KB，GC pause 下降 40% - 忽略
HandshakeTimeout和WriteDeadline，压测客户端断连后服务端连接卡在conn.ReadMessage()，堆积 goroutine - 盲目开启
EnableCompression: true却没配CompressionLevel，小消息（ - 没用
Upgrader.CheckOrigin或直接返回true，压测工具伪造 Origin 头触发大量 403 日志刷屏，I/O 成瓶颈
真实吞吐对比要看场景，不是看单指标峰值
在 10k 并发、平均消息 512B、广播比 1:10 的典型推送场景下：
-
gorilla/websocket（调优后）：稳定 8.2k msg/s，P99 延迟 14ms，内存占用 ~28MB（含 runtime） -
nhooyr.io/websocket：同配置下 9.7k msg/s，P99 延迟 9ms，内存 ~16MB —— 优势来自零拷贝写入和自动压缩阈值控制 -
websocket（github.com/moby/websocket）：10.1k msg/s，但需手动管理conn.SetReadLimit()，否则大消息直接 panic
注意：三者在点对点 echo 场景下差距不到 5%，差异全在广播路径和连接生命周期管理。别只跑 ab 或简单 for-loop，要模拟真实业务的读写比例和心跳频率。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
gorilla/websocket 的广播性能陷阱
它的 Conn.WriteMessage() 是阻塞调用，广播时若某客户端网络卡顿，整个广播循环会被拖住。这不是 bug，是设计选择——它把流控交给上层。容易踩的坑：
- 直接在主线程里遍历所有
conn调用WriteMessage，一个慢连接让整批消息延迟秒级 - 没设
conn.SetWriteDeadline()，超时连接不自动清理，goroutine 泄漏 - 用
sync.Map存连接但没做写保护，广播时并发写conn导致 panic: “write tcp: use of closed network connection” - 想用 goroutine 并发写，却忘了
Conn不支持并发写入 —— 必须加锁或走 channel 串行化
真正压出 gorilla 吞吐上限的，从来不是单连接读写速度，而是你怎么组织广播、怎么清理死连接、怎么避免 goroutine 积压。这些细节不调，换哪个库都白搭。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
