pprof定位性能瓶颈需综合goroutine、heap、block、mutex四类profile：用?debug=2查所有goroutine栈确认泄漏，heap profile结合-gcflags="-m"分析逃逸，block超100ms暴露IO/锁阻塞，再交叉验证系统级资源。
用 pprof 抓住 CPU 和内存热点
直接跑 go tool pprof http://localhost:6060/debug/pprof/profile 只能抓到 30 秒 CPU 样本，对长连接服务意义有限——大部分时间 goroutine 在等待 IO，CPU 使用率低但实际卡在系统调用或锁上。真正该抓的是：goroutine、heap、block 和 mutex 四类 profile。
重点看两个：pprof -http=:8080 http://localhost:6060/debug/pprof/goroutine?debug=2 能看到所有 goroutine 的栈，确认是否真有一连接一 goroutine；pprof -http=:8080 http://localhost:6060/debug/pprof/heap 则暴露堆上对象来源，配合 -gcflags="-m" 编译日志，能定位哪些 make([]byte, ...) 或 fmt.Sprintf 悄悄逃逸到了堆上。
- 别只看 topN 函数，要展开 goroutine 栈，确认是
readPump还是writePump卡住，还是卡在sync.Pool.Get分配路径上 - 如果
heapprofile 显示大量[]uint8对象且 size 接近 64KB，基本就是bufio.NewReader未复用或缓冲区过大 -
blockprofile 超过 100ms，说明有 goroutine 长时间阻塞在 channel 发送、锁等待或系统调用（如epoll_wait返回慢）
检查 goroutine 数量与状态是否失控
百万连接不等于百万活跃 goroutine，但很多人误以为“每个连接启两个 goroutine（读+写）”就完事了。问题在于：一旦某条连接断开而 readPump 没及时退出，或 writePump 死锁在 conn.WriteMessage，goroutine 就会泄漏。用 curl http://localhost:6060/debug/pprof/goroutine?debug=1 | wc -l 看总数，再用 ?debug=2 查具体状态。
- 状态为
IO wait是正常；runnable过多（>50k）说明调度器在疯狂找可运行 goroutine，大概率是 channel 缓冲区太小或写入 goroutine 堵死 - 状态为
semacquire表示卡在锁上，检查是否在广播逻辑中用了全局sync.Mutex保护 map - 状态为
chan send或chan recv且长时间不变化，说明 channel 容量不足或消费者没启动/崩溃
验证连接结构体和缓冲区是否真的栈分配
哪怕你写了 var buf [4096]byte，只要把它传给 io.ReadFull(conn, buf[:])，Go 编译器仍可能因“地址逃逸”把它挪到堆上。关键不是你怎么声明，而是它**是否被取地址后传出函数作用域**。
立即学习“go语言免费学习笔记（深入）”；
运行 go build -gcflags="-m -l" main.go（-l 禁用内联，让分析更准），搜索关键字：escapes to heap。常见逃逸点：
-
upgrader.Upgrade(w, r, nil)返回的*websocket.Conn必然逃逸——它要活到 handler 外，所以连接管理结构体本身必须堆分配 -
make([]byte, 65536)动态大小 + 大于 32KB，默认逃逸；改用[65536]byte栈数组 +conn.Read(buf[:])才可能留在栈上 - 任何赋值给
interface{}的操作，比如log.Printf("%v", conn.RemoteAddr())，都会触发装箱逃逸
观测系统级资源是否成为隐性瓶颈
pprof 再准也看不到文件描述符耗尽、TCP 缓冲区打满或内核 epoll 性能拐点。这些得靠系统指标交叉验证。
- 查
cat /proc/<pid>/fd | wc -l</pid>和ulimit -n，确认 fd 没触顶；若接近上限，netstat -s | grep -i "connection resets"看是否有因ENFILE被内核拒绝的连接 - 用
ss -i观察每个连接的rcv_space和snd_cwnd，若大量连接rcv_space为 0，说明应用层读太慢，内核缓冲区堆满，触发 TCP 流控 - 运行
perf record -e syscalls:sys_enter_accept4,syscalls:sys_enter_epoll_wait -p <pid></pid>，看 accept 和 epoll_wait 是否出现明显延迟毛刺
真正卡住百万连接的，往往不是 Go 代码本身，而是那一行没设 net.ipv4.tcp_rmem、那个忘了 SetConnMaxLifetime 的数据库连接池、或那个在心跳检测里用了 time.Sleep 而非 timer.Reset 的 goroutine。性能瓶颈从来不在单点，而在各层资源预算的缝隙里。
