真实web延迟不能用go test -bench测，因其仅测内存中handler；应分层压测：httptest测逻辑层（需b.resettimer、禁日志、mock依赖），vegeta/wrk测完整网络链路（关连接复用），ghz测grpc，并辅以pprof/trace定位瓶颈。
别用 go test -bench 测真实 Web 延迟——它测的是内存里的 handler，不是你的服务。
用 httptest.NewRequest + b.ResetTimer() 测纯逻辑层性能
这适合验证 HTTP handler 内部是否高效：比如路由匹配、JSON 解析、无锁计算。但它完全绕过 TCP 栈、TLS、连接池、反向代理，结果不能外推到线上。
- 必须调用
b.ResetTimer()，否则httptest.NewRequest和中间件初始化开销会污染耗时 - 禁用日志：
log.SetOutput(io.Discard)，否则log.Printf会把ns/op拉高数倍 - 数据库、Redis、gRPC 调用必须 mock，否则结果不可复现、受外部抖动干扰
- 示例中别漏掉
b.ReportAllocs()，B/op高意味着 GC 压力大，可能比 CPU 更早成为瓶颈
用 vegeta 或 wrk 压真实链路，且必须关掉连接复用
真实压测要走完整网络栈，否则你根本发现不了 TIME_WAIT 爆满、accept 队列溢出、连接池争抢这些典型问题。
-
wrk简单直接：wrk -c 200 -d 30s -t 4 --timeout 5s -H "Connection: close" http://localhost:8080/api/users，-H "Connection: close"强制不复用连接 -
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 - 压测机和服务端必须物理或网络隔离，避免 CPU、网卡、中断共用导致数据失真
- 每次压测前重启服务、清空 Redis/本地缓存、执行两次
runtime.GC()，不然上一轮残留会影响下一轮
压 gRPC 别手写 goroutine——用 ghz，否则容易打爆 fd
手写压测脚本极易误用 grpc.Dial：每 goroutine 新建连接 → 服务端文件描述符耗尽；漏设 WithTimeout → 统计延迟全失真；忽略 WithBlock → 连接阻塞卡死整个 goroutine。
立即学习“go语言免费学习笔记（深入）”；
-
ghz自动管理连接池、支持并发连接数控制（-c）、QPS 限速（-r）、自定义 metadata 和 TLS 配置 - 输出含 P90/P99 延迟、错误码分布、成功请求数，不用自己 parse 日志
- 命令示例：
ghz --insecure -c 50 -z 30s -d '{"id":1}' localhost:9090/user.GetUser - 若用
grpc-go自带 benchmark 模式，需确保 client 复用同一*grpc.ClientConn，且每个请求单独ctx.WithTimeout
边压边采 pprof，三次压测取中位数，否则优化等于蒙眼调参
只看 QPS 和平均延迟，就像只看体温不查血常规——你不知道慢在哪，更不知道改了有没有用。
- 服务启动时加
import _ "net/http/pprof"，压测中执行：curl "http://localhost:6060/debug/pprof/profile?seconds=30" > cpu.pprof - 用
go tool pprof cpu.pprof查热点函数；用go tool trace看 goroutine 阻塞、GC 频次、系统调用等待 - 必须压三次，每次清缓存、重启服务、GC 两次，取中位数——单次结果受 OS 调度、GC 时间点干扰太大
- 特别注意：
mutexprofile查锁竞争，blockprofile查 channel 阻塞或 I/O 等待，这些才是微服务里最常被忽略的隐形瓶颈
真实压测不是跑个工具看个数字，而是控制变量、剥离干扰、定位到行级代码的过程。很多人卡在“为什么 go test -bench 很快但 vegeta 一压就超时”，答案往往藏在连接复用开关、日志级别、或一次没清掉的 Redis 缓存里。
