Benchmark 测单 goroutine 下纯净耗时与内存分配，不模拟并发或 HTTP 请求；压测才检验高并发下服务稳定性。需加 -benchmem 查 allocs/op，用 b.ResetTimer() 避免初始化干扰。
基准测试不是压测，别拿 Benchmark 当 hey 用
Go 的 Benchmark 函数只测单 goroutine 下一段逻辑的**纯净耗时与内存分配**，它不发 HTTP 请求、不建连接、不模拟并发用户，也不关心系统资源打满后是否崩溃。压测（如用 hey、ab 或 vegeta）才真正考验服务在高并发、持续流量下的稳定性、排队延迟、错误率和资源瓶颈。
- 你写
BenchmarkHandleRequest，测的是 handler 函数里解码 + 计算那几十纳秒——跟线上 QPS 毫无关系 - 你用
hey -n 10000 -c 100 http://localhost:8080/api，测的是整个 HTTP 栈、网络、GC、锁竞争、上下文超时等真实链路 - 两者目标不同：
Benchmark是“这段代码快不快”，压测是“这个服务扛不扛得住”
go test -bench 默认不告诉你内存花了多少
不加 -benchmem，你看到的只是 ns/op，完全不知道函数是不是在疯狂 alloc 临时字符串或切片。而内存分配往往是性能退化的真实源头，尤其在高频调用路径上。
- 错误写法：
go test -bench=.→ 只输出类似BenchmarkFib-8 1000000 1245 ns/op - 正确写法：
go test -bench=. -benchmem→ 多出128 B/op 2 allocs/op，立刻暴露逃逸或冗余拷贝 - 若发现
allocs/op高但逻辑简单，大概率是返回了未导出 struct 字段、用了fmt.Sprintf、或 slice append 未预估容量
初始化代码没重置，Benchmark 结果直接废掉
很多人在 Benchmark 函数开头加载配置、构造大 map、读文件，却忘了调用 b.ResetTimer()，导致初始化时间被计入统计——结果虚高 10 倍都很常见。
- 典型错误：
func BenchmarkParseJSON(b *testing.B) {
data := loadBigJSONFile() // 耗时 5ms！
for i := 0; i < b.N; i++ {
json.Unmarshal(data, &v)
}
}
b.ResetTimer()
b.StopTimer() / b.StartTimer()，比如只测解析核心，跳过预热或缓存填充并行基准测试 ≠ 真实压测，并发数由 GOMAXPROCS 和 b.RunParallel 共同决定
b.RunParallel 是让多个 goroutine 并发跑同一段逻辑，但它不模拟请求隔离（无独立 context、无独立连接池），也不触发 HTTP server 的并发调度逻辑，更不会产生 TCP 连接竞争。
- 它适合测纯计算型、无状态、可并行的函数（如加密、压缩、排序）
- 不能替代对
net/httphandler 的压测——因为 handler 里有 mutex、context cancel、中间件链、responseWriter 写锁等真实并发约束 - 运行时实际并发度受
GOMAXPROCS限制；若想压到 100 goroutine，得确保GOMAXPROCS≥ 100，否则会排队等待 M/P
最常被忽略的一点：基准测试结果稳定的前提是「环境干净」——关掉 IDE、暂停其他 Go 进程、避免后台更新，否则 ns/op 波动可能超过 30%。这不是玄学，是 CPU 频率、TLB miss、GC 抢占带来的真实干扰。
