go test -bench 不适合测 http 服务吞吐量，它绕过 tcp 栈、tls、连接池等真实链路环节，仅适合纯计算或本地 i/o 的 benchmark；真实压测应使用 vegeta 或 wrk 并禁用 keep-alive，grpc 应用 ghz，同时必须采集 pprof 数据并验证服务端实际处理状态。
别用 go test -bench 测 HTTP 服务吞吐量
它测的是 handler 函数在内存里跑多快，不是你的微服务在线上能扛多少并发。绕过了 TCP 栈、TLS、连接池、反向代理、甚至 http.Server 的 accept 队列——你压的不是服务，是运气。
- 适合场景：
BenchmarkJSONUnmarshal这类纯计算或本地 I/O，比如解析请求体、生成响应结构体 - 必须加
b.ResetTimer()，否则路由注册、中间件初始化全算进耗时里 - 禁用日志：
log.SetOutput(io.Discard)，否则log.Printf会拖慢几十倍延迟 - 外部依赖必须 mock：数据库、Redis、gRPC 调用不能真实发出去，否则结果不可复现
真实链路压测要用 vegeta 或 wrk，且关掉连接复用
HTTP 压测不是比谁发得快，而是看服务端在真实网络压力下会不会卡死、堆积、超时、OOM。连接复用（Keep-Alive）会让客户端复用 TCP 连接，掩盖服务端连接池打满、TIME_WAIT 溢出、accept 队列阻塞等关键瓶颈。
-
wrk示例（强制每请求新建连接）：wrk -c 200 -d 30s -t 4 --timeout 5s -H "Connection: close" http://localhost:8080/api/users -
vegeta更适合带 body 和 header 的场景：echo "POST http://localhost:8080/api/login" | vegeta attack -body login.json -header "Content-Type: application/json" -rate 100 -duration 30s -timeout 5s | vegeta report - 压测机和服务端必须物理隔离或网络隔离，避免 CPU、网卡争抢干扰结果
gRPC 微服务压测别手写 goroutine，直接用 ghz
手写 goroutine 容易误用 grpc.Dial（每个 goroutine 新建连接 → 打爆服务端 fd）、漏设 WithTimeout（导致统计失真）、忽略 WithBlock()（阻塞在 DNS 解析或连接建立上）。
-
ghz自动管理连接池、支持 QPS 控制、自定义 metadata、输出 P90/P99 和错误码分布 - 示例命令：
ghz --insecure --proto ./api.proto --call pb.UserService.GetUser -d '{"id":"123"}' -c 50 -z 30s localhost:50051 - 如果非要用 Go 写脚本，必须复用
*grpc.ClientConn，并发控制用信号量，所有调用都包在context.WithTimeout里
压测不是只看 QPS，必须边压边采 pprof 数据
没采集 profile 的压测等于盲测。一次靠谱的压测 = 三次独立运行 + 每次清缓存 + 每次重启服务 + 每次 GC 两次 + 取中位数。否则你优化了半天，可能只是某次 GC 恰好没触发。
立即学习“go语言免费学习笔记（深入）”；
- 启动服务时加：
import _ "net/http/pprof"，然后压测中执行：curl "http://localhost:6060/debug/pprof/profile?seconds=30" > cpu.pprof - 重点关注：
go tool pprof cpu.pprof看热点函数；go tool trace看 goroutine 阻塞、调度延迟；go tool pprof --mutexprofile查锁竞争 - 每次压测前手动触发：
debug.FreeOSMemory()（仅测试环境），并重启服务确保状态干净
context deadline exceeded，也没查 /debug/pprof/goroutine?debug=2 里是不是堆了上千个阻塞在 DB 查询上的 goroutine。 
