Go testing 包的基准测试非压测工具：单 goroutine 顺序执行，不模拟并发、不统计 QPS/延迟；-bench 仅测函数性能，绕过网络栈与真实链路，适合算法优化而非 HTTP 服务压测。
Go 自带的 testing 包能做基准测试，但不是压测工具——它单 goroutine 顺序执行、不模拟并发请求、不统计 QPS/延迟分布。真要压测 HTTP 服务，得自己搭或用现成工具（比如 hey、wrk），Go 标准库不提供开箱即用的压力测试框架。
用 go test -bench 测的是函数性能，不是服务吞吐
go test -bench 的本质是反复调用一个函数（如 BenchmarkParseJSON），测量其平均耗时和内存分配。它不建立网络连接，不发 HTTP 请求，也不控制并发数或持续时间。
- 适合场景：优化算法、序列化逻辑、缓存命中路径等纯计算或本地 I/O 操作
- 不适合场景：测
http.Handler响应延迟、查数据库接口的并发承载力、观察 GC 对长连接的影响 - 典型误用：写个
BenchmarkHTTPHandler，里面用httptest.NewRecorder()调用 handler —— 这测的是 handler 内部逻辑，绕过了 net/http 服务器栈、TLS、TCP 握手、反向代理等真实链路
自己写 HTTP 压测工具：核心是控制并发 + 计时 + 收集指标
真正压测 HTTP 服务，需要启动多个 goroutine 并发发请求，记录每个请求的开始/结束时间，并聚合统计。关键点不在“发请求”，而在“怎么管住并发节奏”和“怎么避免统计失真”。
- 别用
for i := 0; i —— 这会瞬间创建 1000 个 goroutine，可能打爆目标服务或本机文件描述符 - 用
semaphore或channel控制并发数，例如：sem := make(chan struct{}, 10) // 限制 10 并发 for i := 0; i < 1000; i++ { sem <- struct{}{} go func() { defer func() { <-sem }() // 发请求、计时、存结果 }() } - 每次请求必须用独立的
*http.Client或复用带超时的 client，避免连接池阻塞；禁用默认重定向：client := &http.Client{ Timeout: 5 * time.Second, Transport: &http.Transport{ MaxIdleConns: 100, MaxIdleConnsPerHost: 100, }, } req, _ := http.NewRequest("GET", "http://localhost:8080/api", nil) req.Close = true // 避免 keep-alive 干扰单请求计时
用 hey 替代手写：更贴近生产环境的真实压力
95% 的 HTTP 服务压测，直接用 hey（Go 写的命令行工具）比手写更可靠——它内置连接复用、动态并发调节、详细的 p90/p95 延迟直方图、失败率统计，且行为可复现。
立即学习“go语言免费学习笔记（深入）”；
- 安装：
go install github.com/rakyll/hey@latest - 基础压测：
hey -n 10000 -c 100 http://localhost:8080/health（1 万请求，100 并发） - 带 body 的 POST：
hey -m POST -d '{"id":1}' -H "Content-Type: application/json" -n 1000 -c 50 http://localhost:8080/api - 注意点：默认启用 keep-alive，若想测“每次新建连接”的场景，加
-disable-keepalive；目标服务日志里看到大量connection reset，大概率是服务端net.Listen的backlog太小或 ulimit 限制过低
压测不是跑通就行，重点在观察服务在不同负载下的拐点：CPU 何时打满、GC 频次是否突增、慢查询是否出现、连接池是否耗尽。这些信号藏在指标里，不在“QPS 数字”本身。
