Go语言基准测试是testing包原生支持的精确测量函数耗时与内存分配的机制；函数需以Benchmark开头、参数为*testing.B、主体用b.N循环。
Go语言基准测试不是“性能测试”的宽泛概念，而是专用于精确测量函数执行耗时与内存分配的标准化机制，由 testing 包原生支持，无需第三方库。
它不评估系统吞吐、并发能力或真实负载下的稳定性——那些属于压测（如用 hey 或 ab）或 pprof 深度分析场景。基准测试只回答一个问题：这段代码，单次调用平均花多少纳秒？分配几次内存？
基准测试函数怎么写：命名、签名、循环缺一不可
一个合法的基准测试函数必须同时满足三项硬约束：
- 文件名以
_test.go结尾，和被测代码同包 - 函数名以
Benchmark开头，例如BenchmarkStringJoin - 参数类型必须是
*testing.B，且主体逻辑必须包裹在for i := 0; i 循环中
错误示例（会被 go test -bench=. 完全忽略）：
立即学习“go语言免费学习笔记（深入）”；
func BenchmarkBad(b *testing.B) {
// ❌ 没有循环 —— 不执行被测代码
strings.Join([]string{"a", "b"}, "")
}
func TestNotBenchmark(t *testing.T) {
// ❌ 是 Test 函数，不是 Benchmark —— 不计时、不统计
for i := 0; i < 100; i++ {
strings.Join([]string{"a", "b"}, "")
}
}
正确骨架：
func BenchmarkStringJoin(b *testing.B) {
parts := []string{"a", "b", "c"} // 初始化放循环外
b.ResetTimer() // 排除初始化开销（关键！）
for i := 0; i < b.N; i++ {
_ = strings.Join(parts, "-") // 被测操作必须在循环内，且结果不能被编译器优化掉
}
}
b.N 是什么：不是固定次数，而是框架动态决定的采样规模
b.N 看似是个整数，实则是 Go 测试框架根据目标函数实际运行时间「反向推导」出的迭代次数。它的目标只有一个：让整个基准测试稳定运行约 1 秒（默认值，可由 -benchtime 调整）。
这意味着：
- 快函数（比如空循环）
b.N可能是百万级；慢函数（比如含time.Sleep(10ms)）b.N可能只有 100 - 你绝不能在循环里写
if i == 0 { setup() }—— 这会污染计时，应统一移到循环外 +b.ResetTimer() -
b.N在单次运行中恒定，但不同机器、不同 Go 版本、甚至不同 GC 压力下都可能变化 —— 所以永远只比同一台机器上的相对值
常见误用：
func BenchmarkWrongN(b *testing.B) {
for i := 0; i < 10000; i++ { // ❌ 硬编码次数 → 时间太短，结果抖动大、无统计意义
_ = someFunc()
}
}
go test -bench=. 输出怎么看：盯住 ns/op 和 allocs/op
运行 go test -bench=. -benchmem 后，典型输出如下：
BenchmarkStringJoin-8 10000000 125 ns/op 32 B/op 1 allocs/op
各字段含义：
-
BenchmarkStringJoin-8：函数名 + GOMAXPROCS（协程并行度） -
10000000：本次实际执行了b.N次 -
125 ns/op：每次调用平均耗时 125 纳秒 —— 这是你横向对比的核心指标 -
32 B/op：每次调用分配 32 字节内存 -
1 allocs/op：每次调用发生 1 次堆内存分配 —— 高频分配易触发 GC，是性能隐形杀手
⚠️ 注意：ns/op 数值本身无绝对意义，只在相同环境、相同基准测试集下才有比较价值。差 2× 可能是算法差异，差 10× 往往意味着有隐式分配或未内联函数。
为什么 b.ResetTimer() 经常被漏掉：初始化开销会严重污染结果
几乎所有真实基准测试都有初始化逻辑：建 slice、开 map、读配置、预热缓存……这些操作只做一次，但若放在循环内，就会被计入耗时；若放在循环外又不重置计时器，它们会把 ns/op 拉高数倍甚至百倍。
正确姿势：
func BenchmarkJSONUnmarshal(b *testing.B) {
data := []byte(`{"name":"go","age":10}`) // 初始化：解析原始字节
var u struct{ Name string; Age int } // 初始化：目标结构体变量
b.ResetTimer() // ✅ 关键一步：从此刻开始计时
for i := 0; i < b.N; i++ {
_ = json.Unmarshal(data, &u) // 只测 Unmarshal 本身
}}
漏掉 b.ResetTimer() 的后果：
- 如果初始化耗时 500μs，而
json.Unmarshal实际只要 500ns，最终ns/op会显示为 ~500500ns（即 500.5μs），完全失真 - 尤其在测试小对象或高频操作时，初始化开销占比越大，误差越致命
真正难的不是写对语法，而是识别哪些代码属于“初始化”、哪些属于“被测核心路径”——这需要你对函数内部行为有清晰拆解。
