go基准测试需手动预热、防优化、分隔初始化，并用benchstat多轮对比，否则结果失真。
Go 的基准测试不是“写个 func BenchmarkXxx 就完事”，它默认只跑一次，不预热、不采样、不校准——直接跑会得到严重失真的结果。
如何让 Benchmark 真正反映真实性能
Go 的 testing.B 不像 JMH 那样自动做预热和多轮采样。默认行为是：用 b.N 控制循环次数，但 b.N 是测试框架动态调整出来的，目标是让单次运行时间落在 1 秒左右；如果函数太快（比如纳秒级），b.N 可能高达百万甚至上亿，而你没做任何防止编译器优化的操作，结果就不可信。
- 必须在循环体里显式使用结果，否则 Go 编译器可能整个优化掉，比如：
result := compute(); _ = result - 避免在
Benchmark函数里做初始化（如make切片、构造 map），除非用b.ResetTimer()切分——初始化耗时会被计入总耗时 - 想测纯计算逻辑？加
b.ReportAllocs()看是否意外触发 GC 或堆分配
go test -bench 常见错误现象和参数含义
运行 go test -bench=. 却发现没输出？或者输出全是 0 B/op 和 0 allocs/op？大概率是没触发实际执行，或被优化掉了。
-
-bench=.匹配所有Benchmark*函数，但若当前目录无_test.go文件，或文件里没定义Benchmark函数，就静默跳过 -
-benchmem必须显式加，否则allocs/op和B/op全是 0 -
-benchtime=5s可延长总运行时长，让短函数有足够迭代次数，避免因b.N太小导致统计抖动大 -
-count=5会跑 5 轮独立 benchmark，配合benchstat工具才能看方差，单次go test不自带统计显著性
对比两个实现时，为什么 BenchmarkA 和 BenchmarkB 不能直接比数字
因为 Go 默认不控制 CPU 频率、后台进程干扰、GC 时间抖动——尤其当两个函数分配行为差异大（一个堆分配多、一个全栈）时，ns/op 数值会受 GC 周期影响剧烈波动，单纯看平均值毫无意义。
- 务必用
benchstat（go install golang.org/x/perf/cmd/benchstat@latest）比对多轮结果，例如：benchstat old.txt new.txt - 如果函数涉及 channel、锁、goroutine，要小心调度器干扰——这种场景下
ns/op解释力很弱，更应关注吞吐量（如ops/sec）或尾延迟 - 别忘了
runtime.GC()在Benchmark开头手动触发一次，减少首轮 GC 对后续轮次的影响
真正难的不是写 Benchmark 函数，而是理解你测的到底是什么：是纯 CPU 时间？含内存分配开销？受 GC 影响有多大？有没有被编译器吃掉？这些不厘清，数字再好看也没法指导优化。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
