pprof采集不到有效数据？先确认三件事：服务是否有真实请求、pprof是否在独立goroutine运行且主goroutine未退出、CPU profile采样是否满30秒，否则改用heap或goroutine接口即时查看。
pprof 采集不到有效数据？先确认这三件事
pprof 不是“开箱即用”，很多团队跑完 go tool pprof http://localhost:6060/debug/pprof/profile?seconds=30 却发现火焰图一片平，或只看到 runtime 调度器函数——根本原因是服务没真正在处理请求。
- 确保压测流量已打到目标服务（检查 access log 或
netstat -an | grep :6060确认 pprof 端口有连接） - pprof 默认只暴露在
localhost，若用容器或远程压测，需改成http.ListenAndServe("0.0.0.0:6060", nil) - Go 1.20+ 默认禁用
/debug/pprof/的某些 endpoint（如/goroutine?debug=2），需显式导入import _ "net/http/pprof"且不被 build tag 排除
block profile 显示大量 chan send？别急着加缓冲
当 go tool pprof -http=:6060 http://localhost:6060/debug/pprof/block 中 runtime.chansend 占比超 30%，说明 channel 已成串行瓶颈，但盲目调大 buffer 可能掩盖更深层问题。
- 先查发送方是否在循环里无节制写入（比如日志模块每条消息都
ch ） - 缓冲大小不是越大越好：
buffer=1000只是把阻塞从“立刻发生”延后到“填满才发生”，仍会卡住生产者 - 真正解法是改用
select { case ch ，避免 goroutine 永久挂起 - 若 channel 仅用于计数或状态广播，直接换成
atomic.AddInt64或sync.Map更轻量
Goroutine 数量飙到 10k+？大概率是泄漏而非并发需求
pprof 的 /goroutine?debug=2 显示活跃 goroutine 超过 10k，90% 情况下不是业务需要这么多并发，而是某处协程没退出。
- 典型泄漏模式：未关闭的 channel 导致
for range ch永远阻塞；HTTP handler 里启 goroutine 但没配context超时 - 检查
net/http的 handler 是否用了go func() { ... }()而没做并发控制（如 worker pool） - 用
runtime.NumGoroutine()定期打点，观察增长趋势——稳定服务不应随时间线性上升 - 修复后验证：重启服务，压测 5 分钟，goroutine 数应回落到初始值附近（±20%）
GC 频繁但内存没涨？看分配热点而非总量
GC 次数 >50 次/分钟 + GODEBUG=gctrace=1 显示 STW 时间短，说明问题不在内存泄漏，而在高频堆分配。
立即学习“go语言免费学习笔记（深入）”；
- 用
go tool pprof http://localhost:6060/debug/pprof/heap?alloc_space查“累计分配字节数”，定位高频 new 对象的函数 - 常见坑：JSON 序列化中反复
json.Marshal、HTTP body 读取后未复用bytes.Buffer、中间件里每次请求 new struct - 优先用
sync.Pool复用临时对象（如[]byte、bytes.Buffer），但注意 Pool 对象不能含 finalizer 或跨 goroutine 引用 - 避免在 hot path 上做字符串拼接：
fmt.Sprintf比strings.Builder开销高 3–5 倍
真实瓶颈往往藏在“看起来正常”的地方：pprof 数据采样窗口太短、goroutine 泄漏初期只多几百个、GC 频繁但单次停顿不到 1ms——这些信号容易被忽略，却决定了系统能否扛住突发流量。
