真实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。
