wrk的-t应设为CPU逻辑核心数（如8核用-t8），-c需逐步递增测试QPS线性增长点；避免-t1-c1000等失真配置，因单线程高连接会掩盖调度开销并干扰latency统计。
wrk 和 hey 都能压测 Go Web 服务，但它们不是同一类工具：wrk 是面向吞吐量与延迟极限的基准测试器，hey 是面向开发调试与场景模拟的负载生成器。选错会导致数据失真或排查方向跑偏。
wrk 的 -t 和 -c 参数怎么配才不误导结果
很多人直接套用 -t4 -c400，但 wrk 的线程数 -t 和连接数 -c 不是线性关系。它用 epoll 管理连接，每个线程可维持数百连接；-t 过大会引发内核调度抖动，-c 过小则无法打满后端。
-
-t建议设为 CPU 逻辑核心数（如 8 核就用-t8），不超过runtime.NumCPU()返回值 -
-c应逐步递增：从-c50开始，每次 +50，观察 QPS 是否线性增长；一旦增长放缓，说明瓶颈已在服务端或系统层 - 避免
-t1 -c1000这类配置——单线程扛千连接会掩盖真实调度开销，且latency统计在高并发下易受 goroutine 抢占干扰
hey 的 -q 和 -c 同时设置时的实际行为
hey -c100 -q10 并不是“每秒发 1000 个请求”，而是启动 100 个 goroutine，每个 goroutine 每秒最多发 10 个请求（即总速率上限约 1000 QPS）。这个机制对模拟“用户节流”很实用，但容易误读为纯并发控制。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 若目标是测服务最大吞吐，应省略
-q，只用-c+-n（如hey -c200 -n10000） - 若要模拟带退避的客户端（比如前端防抖、重试逻辑），才启用
-q；此时响应时间分布会更贴近真实用户，但 QPS 不稳定 -
-q值大于 50 后，goroutine 调度开销开始明显，实测中-q100反而比-q50的吞吐低 12% 左右（Gin 示例服务，Linux 6.6 内核）
HTTP/2 场景下必须用 hey，wrk 不支持
wrk 完全不解析 HTTP/2 帧，即使你用 https:// 地址，它也降级走 HTTP/1.1。如果你的 Go 服务启用了 http2.ConfigureServer 或用 net/http.Server.TLSConfig.NextProtos = []string{"h2"}，wrk 的测试结果毫无参考价值。
- 确认服务是否真走 HTTP/2：用
curl -I --http2 https://localhost:8443/health看响应头是否有HTTP/2 200 - hey 默认支持 HTTP/2，无需额外参数；但需确保 Go 版本 ≥ 1.16（旧版 TLS 握手不协商 h2）
- 若 hey 报
http2: server sent GOAWAY and closed the connection，大概率是服务端http2.Server的MaxConcurrentStreams设得太小（默认 250），调高到 1000 再试
真正难的是区分「工具瓶颈」和「服务瓶颈」：wrk 的高 QPS 可能只是它自己没发出去，hey 的长尾延迟可能来自客户端 DNS 缓存或 TLS 重协商。压测前先用 hey -o csv 导出原始数据，比看终端 summary 更可靠。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
