go test -bench 不适合测并发负载，因其仅在单进程内调度 goroutine，不建立真实 TCP 连接、不触发 socket 栈、连接池、accept 队列或 TLS 握手等真实网络链路，测得的是逻辑吞吐而非接口吞吐。
直接用 hey 测，别写代码跑 go test -bench —— 它压不出真实网络瓶颈，也测不了连接耗尽、TIME_WAIT、DNS 阻塞这些关键问题。
为什么 go test -bench 不适合测并发负载
go test -bench 的 B.RunParallel 本质还是单进程内调度 goroutine，不建真实 TCP 连接，不走系统 socket 栈，也不触发客户端连接池、服务端 accept 队列、TLS 握手排队等真实链路。它测的是“逻辑吞吐”，不是“接口吞吐”。你看到 BenchmarkXxx-8 1000000 1245 ns/op 很漂亮，但上线后一压就卡在 connect: cannot assign requested address 或响应毛刺飙升，和这数字毫无关系。
- HTTP 接口压测必须走外置工具：真实发包、复用/耗尽连接、暴露网络层问题
- 本地起
http.Server做被测对象时，go test还会干扰 GC 和 pprof 采样，结果不可比 - 想验证高并发下代码是否 panic / 数据错乱？那是
go test -race的事，不是-bench的事
怎么装 hey 才不卡在 “command not found”
别用 go install github.com/rakyll/hey@latest。Go 1.21+ 默认 GOPROXY=direct，国内基本拉不到模块，报 no matching versions 或卡死在 resolving。
- Linux：
wget https://storage.googleapis.com/hey-releases/hey_linux_amd64 -O /usr/local/bin/hey && chmod +x /usr/local/bin/hey - macOS：
curl -L https://storage.googleapis.com/hey-releases/hey_darwin_amd64 -o /usr/local/bin/hey && chmod +x /usr/local/bin/hey - Windows：下载
hey_windows_amd64.exe，重命名为hey.exe，加进%PATH% - 验证：
hey -h能输出帮助即成功；路径里不能有空格或中文，否则hey -z 10s http://a.com会静默失败
hey -c 和 -q 怎么配才打得出稳态压力
-c 是并发 worker 数（同时开多少 goroutine），-q 是每个 worker 每秒最多发几个请求。两者相乘才是理论 QPS 上限，但实际受服务端吞吐、DNS 解析、本地端口范围限制。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 只设
-c 1000不设-q：瞬间打爆本机 socket，报socket: too many open files - 只设
-q 100但-c 1：只有一个 worker，根本打不出稳定 100 QPS，波动极大 - 目标是稳态压测（比如验证能否扛住 300 QPS）：建议
-c设为-q的 2–5 倍，例如-c 200 -q 50，比-c 50 -q 200更稳——后者容易因单个 worker 卡顿拖垮整体节奏 - 加
-disable-keepalive：否则服务端TIME_WAIT和accept队列堆积会被掩盖
压出来 QPS 上不去？先查这三处
常见现象：hey -c 100 -n 10000 http://localhost:8080/api，QPS 卡在 200–500，CPU 却没跑满。大概率不是 Go 代码慢，而是某层卡住了。
- 服务端
http.Server.ReadTimeout/WriteTimeout太小，导致连接频繁中断重连 - 客户端默认 HTTP/1.1 没开 keep-alive；可加
-h "Connection: keep-alive"或换wrk - Linux 本地端口耗尽：
net.ipv4.ip_local_port_range默认是32768 60999，100 并发 × 多轮请求容易撞上限；临时调大：sudo sysctl -w net.ipv4.ip_local_port_range="1024 65535"
真正难的不是并发数，而是让每个请求都走通、不卡在 DNS、不耗尽连接、不拖垮本地网络栈。压测前先跑通 pprof，看 goroutine 数、GC 频率、阻塞点——这些比 QPS 数字更能说明问题。
