WebSocket 长连接测试为什么不能用 http.Get 直接连
因为 http.Get 是 HTTP 矋请求，不支持 WebSocket 协议升级（Upgrade: websocket），直接调用只会收到 400 Bad Request 或 426 Upgrade Required。真实长连接必须走 websocket.Dial 建立底层 TCP 连接并完成握手。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
gorilla/websocket（最常用）或golang.org/x/net/websocket（已归档，不推荐新项目） - 测试时务必设置
websocket.DefaultDialer.Proxy = http.ProxyFromEnvironment，否则内网/代理环境会静默失败 - 超时必须显式设：
&websocket.Dialer{Timeout: 5 * time.Second}，默认无超时，测试卡住难定位
并发发消息时 conn.WriteMessage panic: concurrent write
WebSocket 连接对象 *websocket.Conn 的写操作不是 goroutine 安全的——多个 goroutine 同时调用 WriteMessage 会触发 panic: concurrent write to websocket connection。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 每个连接只启动一个写 goroutine，用
chan []byte做消息队列，主逻辑往 channel 发，写 goroutine 从 channel 取并调用WriteMessage - 避免在测试中用
for i := 0; i 这类裸并发 - 如果需模拟多客户端并发，应为每个 client 创建独立
*websocket.Conn，而非复用同一个连接
如何验证消息链路端到端不丢、不乱序
WebSocket 本身保证 TCP 层有序，但业务层可能因读写协程竞争、缓冲区截断、心跳干扰导致逻辑错乱。单纯看「有没有收到」不够，要验证内容和顺序。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 服务端发消息时带上单调递增的
seq_id（如{"seq": 123, "data": "..."}），客户端按序号校验是否跳变或重复 - 客户端读消息必须用
conn.ReadMessage阻塞读，别用Select+default跳过，否则会漏帧 - 关闭连接前，强制等所有待发消息 flush：调用
conn.SetWriteDeadline(time.Now().Add(1 * time.Second))后再WriteMessage，最后conn.Close()
测试压测时 CPU 暴涨但连接数上不去
常见于未控制 goroutine 泄漏或 net.Conn 底层 fd 耗尽。现象是 go tool pprof 显示大量 runtime.gopark 或 net.(*pollDesc).waitRead，且 lsof -p <pid> | wc -l</pid> 远超预期。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 每个测试 client 必须显式调用
conn.Close()，并在defer中包裹，别依赖 GC - 限制最大并发连接数，用
semaphore.NewWeighted(int64(maxConns))控制 goroutine 数量 - Linux 下检查
/proc/<pid>/fd</pid>数量，确认没突破ulimit -n；必要时在测试前执行ulimit -n 65536
真正难调的是跨 goroutine 的读写状态同步——比如心跳 goroutine 和业务消息 goroutine 共享同一连接但没加锁，这种问题不会报错，但会在高负载下间歇性丢帧。得靠带 seq 的日志 + 抓包双向比对才能定位。
