go test -bench 无法测出真实并发压力，因其仅在单进程内调度goroutine，不模拟多客户端、网络栈、连接复用/耗尽等真实瓶颈；http接口压测必须使用hey、wrk或vegeta等外部工具。
用 go test -bench 跑不出真实并发压力？
默认的 testing.B 是单 goroutine 循环执行，哪怕你写 b.RunParallel，底层也只在测试进程内调度，不模拟多客户端、不压网络栈、不触发连接复用/耗尽等真实瓶颈。
真正要测高并发接口（比如 HTTP 服务），得用外部工具打真实 TCP 连接。否则 benchmem 再好看，也掩盖不了 http.Transport 配置不当、TLS 握手阻塞、或连接池打满时的毛刺。
-
go test -bench只适合测纯函数、编解码、内存分配等无 I/O 的逻辑 - HTTP 接口基准测试必须走外置压测：推荐
hey（轻量）、wrk（高吞吐）、或vegeta（支持持续压测） - 别在
BenchmarkXxx里起http.Server—— 端口冲突、GC 干扰、无法复现TIME_WAIT积压等问题会污染结果
hey -c 100 -n 10000 压出来 QPS 低得离谱？检查这三处
常见现象是：本地跑 hey -c 100 -n 10000 http://localhost:8080/api，QPS 卡在 200–500，CPU 却没跑满。大概率不是 Go 代码慢，而是客户端或服务端某层卡住了。
- 服务端
http.Server.ReadTimeout/WriteTimeout设得太小，导致连接频繁中断重连 - 客户端（
hey默认用 HTTP/1.1）没开 keep-alive；加-h "Connection: keep-alive"或换wrk -H "Connection: keep-alive" - Linux 本地端口耗尽：
net.ipv4.ip_local_port_range默认是32768 60999，100 并发 × 多轮请求容易撞上限；临时调大：sudo sysctl -w net.ipv4.ip_local_port_range="1024 65535"
分布式负载模拟时，http.Transport 的 MaxIdleConnsPerHost 必须显式设大
多个压测节点共用一个后端服务时，如果每个节点的 Go 客户端（比如用 vegeta 自定义脚本）不调大连接池，默认 MaxIdleConnsPerHost = 2，会导致大量请求排队等空闲连接，压不出真实吞吐。
立即学习“go语言免费学习笔记（深入）”；
实操建议：
- 服务端侧：确保
http.Server的MaxHeaderBytes和ReadBufferSize足够，避免因缓冲区小引发额外系统调用 - 客户端侧（如用 Go 写压测脚本）：
http.DefaultTransport.(*http.Transport).MaxIdleConnsPerHost = 1000 - 别依赖
http.DefaultClient—— 它的 Transport 是全局共享的，不同测试用例之间会互相干扰
用 pprof 看火焰图，但 runtime/pprof 抓不到真实瓶颈？
直接在压测中跑 curl http://localhost:6060/debug/pprof/profile?seconds=30，常看到一堆 runtime.mcall 或 runtime.futex，但这只是表象 —— 真正的瓶颈可能在锁竞争、GC 暂停、或 syscall 阻塞上。
- 先看
goroutineprofile：curl "http://localhost:6060/debug/pprof/goroutine?debug=2"，确认有没有 goroutine 卡死（比如等 channel、等锁、等 DB 连接） - 再抓
trace：curl "http://localhost:6060/debug/pprof/trace?seconds=20"，用go tool trace打开，重点看“Network blocking”和“Syscall”时间占比 - 如果 GC 频繁，
go tool pprof加-http后点 “View > Top > runtime.gcBgMarkWorker” 查标记协程占用
压测中 profile 数据失真很常见：采样频率、GC 触发时机、甚至 pprof handler 本身也在抢锁。最好压稳 30 秒后再抓，且避开前 5 秒冷启动期。
