大量连接卡在handshake因http.Transport默认配置宽松导致TCP连接未及时释放，需显式设置Dialer超时、禁用HTTP/2、限制本地端口范围、避免复用Client实例。
用 gorilla/websocket 模拟高并发连接时，为什么大量连接卡在 handshake？
因为默认的 http.Transport 对连接复用和超时控制太宽松，底层 TCP 连接没及时释放，dialer 会阻塞在 DNS 解析或 TLS 握手阶段。尤其在短时发起数千连接时，本地端口耗尽、TIME_WAIT 积压、DNS 缓存未生效都会放大问题。
- 显式设置
Dialer.Timeout和Dialer.KeepAlive，比如10 * time.Second和30 * time.Second - 禁用 HTTP/2：
http.DefaultTransport.(*http.Transport).TLSNextProto = make(map[string]func(string, *tls.Conn) http.RoundTripper)，避免握手协商开销 - 用
net.Dialer控制本地端口范围（如LocalAddr: &net.TCPAddr{Port: 0}）避免 bind 失败 - 别复用同一个
http.Client实例做千级并发 dial —— 每个 goroutine 应该用独立Dialer实例，否则锁争用严重
websocket.WriteMessage 频繁报 write tcp: use of closed network connection 怎么办？
不是网络问题，是连接被主动关闭后，还有 goroutine 在往已关闭的 *websocket.Conn 写数据。常见于：心跳检测失败后只关读、没同步关写；或 panic 后 defer 没覆盖全部路径。
- 写操作前加
if conn == nil || conn.IsClosed() { return }，IsClosed()是gorilla/websocketv1.5+ 提供的非阻塞判断 - 写逻辑必须包裹在
select中监听conn.CloseNotify()或自定义 done channel，一收到关闭信号立刻退出写循环 - 避免在
WriteMessage后立刻调用Close()—— 改用WriteControl(websocket.CloseMessage, ...)主动发 close 帧，再等对方响应 - 测试时用
conn.SetWriteDeadline(time.Now().Add(500 * time.Millisecond))暴露写阻塞问题，比默认无限等待更易定位
压测中 CPU 突增但 QPS 上不去，runtime/pprof 显示大量 websocket.preparedMessage 占用堆内存
这是典型的消息预分配滥用：每次调用 WriteMessage 都会拷贝 payload 并封装成 preparedMessage，如果反复发送相同小消息（如心跳 ping），对象分配频率极高，GC 压力陡增。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 对固定内容（如
"ping"）提前构建websocket.PreparedMessage实例，复用而非每次都 new - 用
conn.WriteControl()发送 ping/pong —— 它不走 message 编码流程，零分配 - 关闭
WriteBufferPool（设为nil）反而更稳：压测场景下 pool 的 lock 争用常比分配还重 - 检查是否误将大结构体 JSON 序列化后直传给
WriteMessage—— 应先序列化到[]byte再传，避免闭包捕获导致逃逸
如何让单机压出 10w+ WebSocket 连接而不 OOM 或卡死？
关键不在 Go 并发模型多强，而在 OS 层和连接生命周期管理是否精细。Golang 能跑满连接数，但系统限制和连接“假活”才是瓶颈。
立即学习“go语言免费学习笔记（深入）”；
- 调高系统参数：
ulimit -n 1000000、sysctl -w net.core.somaxconn=65535、关闭net.ipv4.tcp_tw_reuse（压测环境可开，但需确认服务端也配好） - 每个连接必须带独立 context，并在 goroutine 启动时就监听 cancel —— 别等 write/read 报错才退出
- 禁用
SetReadDeadline的绝对时间模式，改用SetReadLimit+ 心跳计数器，避免大量 timer 对象堆积 - 连接建立后立即发一次 ping 并等待 pong，失败则立刻 close —— 防止“半开连接”占着 fd 不放
真正难的不是启动连接，是让它们按预期断开。很多压测脚本卡在 8w 连接不动，其实是 2w 连接早已静默断连却没被回收，fd 被占着，新连接 bind 失败。盯着 /proc/<pid>/fd</pid> 和 ss -s 才能看清真相。
