go test -bench=. 执行当前包所有Benchmark函数，需加-benchmem看内存分配，-benchtime和-count提升结果稳定性，b.N由框架自动调节。
go test -bench=. 是最常用的基准测试命令
直接运行 go test -bench=. 就能执行当前包下所有以 Benchmark 开头的函数。注意这个点（.）是正则表达式，表示“匹配任意字符串”，不是通配符或文件名。它会扫描所有 *_test.go 文件，找到符合命名规则的函数并执行。
常见错误是漏掉 -bench 参数，只写 go test —— 这默认只跑单元测试（Test* 函数），基准测试完全不会触发。
- 想只测某一个函数？用
go test -bench=BenchmarkSum（注意大小写和拼写必须完全一致） - 怕单元测试干扰输出？加
-run=^$或-run=none，确保不执行任何Test*函数 - 测试文件不在当前目录？需显式指定包路径，例如
go test ./pkg/math -bench=.
-benchmem 要加，否则看不到内存分配真相
-benchmem 不是可选彩蛋，而是性能分析的刚需开关。不加它，你只能看到耗时（ns/op），但完全不知道函数是否在疯狂分配内存——而 GC 压力往往比 CPU 更伤实际吞吐。
加上后输出会多出两列：X B/op 和 Y allocs/op。比如 112 B/op 3 allocs/op 表示每次调用平均分配 112 字节、触发 3 次堆分配。这对识别切片预分配、避免闭包捕获、判断是否该用 sync.Pool 极其关键。
- 分配量突增？检查是否在循环里反复
make([]T, n)或构造新 map - allocs/op > 0 但 B/op = 0？可能是小对象逃逸到堆，用
go build -gcflags="-m"看逃逸分析 - 想压测 GC 影响？配合
-benchtime=10s延长运行时间，让 GC 有足够机会介入
b.N 不是你能手动设的，但可以靠 -count 和 -benchtime 控制稳定性
b.N 是测试框架自动调节的迭代次数，目标是让单次基准测试总耗时接近 1 秒（默认值）。它从 1 开始试跑，按序列 1, 2, 5, 10, 20, 50, 100... 递增，直到耗时稳定且满足精度要求。你不能、也不该在代码里写 b.N = 10000 —— 这会破坏统计意义。
真正可控的是外部参数：
-
-benchtime=3s：让每次测试至少跑够 3 秒，减少单次波动影响 -
-count=5：重复整个基准测试 5 次，go test默认只跑 1 次，单次结果容易受系统抖动干扰 -
-cpu=1,2,4：分别测试单核/双核/四核下的表现，尤其对并发逻辑（如sync.Map）很重要
实操建议：日常调优用 go test -bench=. -benchmem -benchtime=3s -count=3，结果更可信。
并发基准测试必须用 b.RunParallel，别手写 goroutine
想测高并发场景？千万别在 for i := 0; i 里自己起 goroutine——这会导致 goroutine 数量失控、调度混乱，结果毫无参考价值。
正确姿势是用 b.RunParallel，它由测试框架统一管理 worker 数量（默认等于 GOMAXPROCS），每个 worker 持续调用 pb.Next() 直到完成全部 b.N 次工作。这样既真实模拟并发负载，又保证总操作数可控。
func BenchmarkMapStoreParallel(b *testing.B) {
m := sync.Map{}
b.RunParallel(func(pb *testing.PB) {
for pb.Next() {
m.Store("key", "value")
}
})
}
- 想限制并发度？用
b.SetParallelism(n)（n 是 worker 数），而不是改GOMAXPROCS - 初始化开销大？仍需在
b.RunParallel外做，并用b.ResetTimer()排除 - 结果里的
-8后缀不是 CPU 核心数，而是当时生效的GOMAXPROCS值，可通过-cpu参数覆盖
最容易被忽略的一点：基准测试里所有被测逻辑的返回值，必须被实际使用（比如赋给全局变量 blackhole 或参与后续计算），否则 Go 编译器可能直接优化掉整条调用链——你测的根本不是原函数，而是一段空操作。
