压测需结合pprof定向分析才能暴露Go真实性能瓶颈：启用net/http/pprof，用hey等工具稳定压测30秒以上，采集CPU/堆profile，重点关注runtime.findrunnable（>15%提示goroutine失控）和sync.runtime_SemacquireMutex（提示锁争用），并调优GOGC、GOMAXPROCS及容器CPU限制。
压测本身不会自动暴露 Go 性能瓶颈，关键在于「怎么压」和「压完看什么」——盲目用 ab 或 hey 打高并发，大概率只看到 502 或 connection refused，根本定位不到 runtime.goroutine 泄漏、sync.Mutex 争用或 http.Server.ReadTimeout 配置失当这类真实问题。
用 pprof + 真实请求路径做持续压测
Go 的性能分析必须绑定具体业务路径，不能只压 /health。启动服务时确保已启用 pprof：
import _ "net/http/pprof"
func main() {
go func() {
log.Println(http.ListenAndServe("localhost:6060", nil))
}()
// ... 启动你的 HTTP server
}
压测时同步采集：go tool pprof http://localhost:6060/debug/pprof/profile?seconds=30（CPU）或 ?seconds=30&debug=1（堆内存）。注意：压测时间必须 ≥ 30 秒，否则采样不足；且压测流量要稳定（比如用 hey -z 60s -q 10 -c 50 http://localhost:8080/api/order），避免脉冲式请求干扰 profile 结果。
重点关注 runtime.findrunnable 和 sync.runtime_SemacquireMutex
pprof 分析时，用 top 命令查看热点函数，以下两类信号高度提示瓶颈：
立即学习“go语言免费学习笔记（深入）”；
-
runtime.findrunnable占比 > 15% → goroutine 调度开销过大，常见于 goroutine 数量失控（如每请求启 100 个 goroutine 且未限制）或 channel 阻塞严重 -
sync.runtime_SemacquireMutex高频出现 → 锁争用，典型场景是全局map加sync.RWMutex，但读多写少却用了Lock()而非RUnlock()
此时应检查代码中是否在热路径上做了不必要的同步操作，比如把 time.Now() 放在锁内、或用 log.Printf 记录高频字段。
别忽略 GOGC 和 GOMAXPROCS 对压测结果的扭曲
默认 GOGC=100 在压测中可能引发频繁 GC，掩盖真实 CPU 瓶颈；GOMAXPROCS 若未显式设置，在容器中常被限制为 1（尤其 Kubernetes 默认不设 resources.limits.cpu），导致压测时 CPU 利用率卡在 100%，但实际只跑一个 P。
- 压测前加环境变量：
GOGC=200 GOMAXPROCS=4（根据宿主机 CPU 核数调整） - 用
go tool pprof http://localhost:6060/debug/pprof/gc查看 GC 频次，若 30 秒内触发 ≥ 5 次，说明 GC 成为瓶颈而非业务逻辑 - 容器部署时务必设置
resources.limits.cpu，否则runtime.NumCPU()返回值不可靠
真正卡住 Go 服务的，往往不是算法复杂度，而是 context.WithTimeout 忘传入下游调用、http.Client 缺少 Transport.MaxIdleConnsPerHost、或者日志库在 io.WriteString 时阻塞了整个 goroutine——这些细节只有在可控压测 + pprof 定向抓取下才看得见。
