go test -bench=. 无输出是因为未满足四个硬性条件：文件名须以_test.go结尾、函数名须以benchmark开头、参数类型须为*testing.b、循环体须用b.n控制次数；任一缺失即被静默忽略。
go test -bench=. 什么都没输出？检查这四个硬性条件
Go 的 benchmark 不是写了函数就能跑，缺一不可：文件名必须以 _test.go 结尾、函数名必须以 Benchmark 开头、参数类型必须是 *testing.B、循环体必须用 b.N 控制次数。任意一条不满足，go test -bench=. 就会静默忽略——不是没跑，是压根没识别到。
常见错误包括：func BenchmarkX(t *testing.T)（错用 *testing.T）、func benchmarkX(b *testing.B)（小写开头）、main_test.go 里写了但没放在被测包目录下、或者循环写成 for i := 0; i （硬编码而非 <code>b.N）。
- 用
go list -f '{{.TestGoFiles}}' ./...确认_test.go文件是否被 Go 工具链识别 - 运行
go test -v -bench=.，加-v能看到“no benchmarks to run”提示，比空白输出更早暴露问题 - 别在
go mod init之外的目录执行测试，否则包路径解析失败导致找不到测试函数
ns/op 数值不准？别直接比，先控变量
默认 go test -bench=. 每个函数各自跑满约 1 秒，b.N 自动调整。这意味着两个函数实际执行次数可能差几十倍，ns/op 数值不能直接横向对比——比如一个函数单次耗时 100ns（b.N=10000000），另一个耗时 10μs（b.N=100000），但都显示“约 1 秒”，数值失真。
要公平对比，必须统一测试规模或延长基准时长：
- 加
-benchtime=5s把总时长拉到 5 秒，减少计时抖动影响 - 对关键函数用
-count=3多跑几次取中位数，避免单次 GC 或 CPU 频率波动干扰 - 若需固定迭代次数（比如都跑 10 万次），改用
-benchtime=100000x（注意是x不是s） -
-benchmem必须显式加，否则allocs/op恒为 0；且b.ReportAllocs()要写在for循环前，否则不生效
为什么结果每次都不一样？系统干扰比代码本身影响更大
笔记本上跑出的 BenchmarkFoo-8 1200000 980 ns/op 和服务器上跑出的 1120 ns/op，差的往往不是算法，而是 CPU 频率、后台进程、GC 时间点。Go 的 testing.B 不做任何系统隔离，全靠你手动挡。
实操上最有效的稳定手段：
- Linux 下临时切性能模式：
echo performance | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor - Mac 上关掉 Slack、Chrome、iTerm 这类常驻唤醒进程，用
powermetrics --samplers sched,proc | grep "idle wakeups"看是否低于 50/s - 测试前手动触发 GC：
runtime.GC()放在b.ResetTimer()前，清空堆压力 - 避免在
b.ResetTimer()前做任何非被测逻辑，比如make([]byte, 1 —— 这部分内存分配和初始化时间会被计入基准
怎么防止编译器把你的被测代码优化掉？
Go 编译器很聪明，如果它发现某个计算结果完全没被使用，就可能直接跳过整段逻辑。典型表现是：函数明明有副作用或耗时操作，但 ns/op 低得离谱（比如 1ns），甚至 allocs/op 为 0。
安全写法只有两种：
- 把返回值赋给一个变量，再用
_ = result显式声明“我需要这个值”，例如：result := ConcatStrings(strs); _ = result - 对关键中间变量加
blackhole：定义全局变量var blackhole interface{}，最后写blackhole = result，确保逃逸分析无法消除 - 用
go tool compile -gcflags="-m" your_file.go检查关键结构体是否出现escapes to heap，如果逃逸了，说明你测的其实是内存分配+GC开销，不是纯计算性能
真正难的不是写 benchmark，是让 benchmark 测的确实是你要测的东西——初始化、GC、编译器优化、系统调度，每一步都可能悄悄篡改结果。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
