Go基准测试必须以Benchmark开头且参数为testing.B，这是go test -bench识别的硬性约定；否则静默忽略。testing.B提供b.N、b.ResetTimer()等关键控制点，确保性能数据可比、可复现、可归因。
Go 原生测试框架自带的基准测试能力，不是“可选配件”，而是性能调优的第一现场——你不需要装任何第三方库，go test -bench 就能直接跑出可比、可复现、可归因的性能数据。
为什么 Benchmark 函数必须以 Benchmark 开头且参数是 *testing.B
这是 Go 测试驱动器识别基准测试的硬性约定。不满足就完全不会被 go test -bench 扫描到，也不会执行。编译器和 testing 包靠这个签名做静态分发。
-
Benchmark前缀让go test在扫描时跳过普通Test函数，只挑出性能测试入口 -
*testing.B提供了b.N（自动调整的循环次数）、b.ResetTimer()（排除初始化开销）、b.ReportAllocs()（开启内存分配统计）等关键控制点 - 如果写成
func BenchFoo(b *testing.T)，会编译通过但静默忽略——不会报错，也不会运行
go test -bench=. 默认行为与常见陷阱
它会运行所有匹配的 Benchmark* 函数，但默认不报告内存分配，也不排除 setup 代码干扰，容易得出虚高或不可比的结果。
- 必须显式加
-benchmem才显示 allocs/op 和 bytes/op，否则只输出 ns/op - 初始化逻辑（如构建 map、预分配 slice）要放在
b.ResetTimer()之前，否则计入耗时 -
b.N是动态确定的：框架会先试跑少量次数估算单次耗时，再放大到总时间约 1 秒，所以不同机器/负载下b.N值可能差几倍——比较时只看 ns/op，别比b.N - 避免在循环内做 I/O 或调用
time.Now()等非纯操作，否则b.N调整逻辑会失准
如何用 -cpuprofile 和 -memprofile 定位真实瓶颈
单纯看 ns/op 只知道“慢”，但不知道“为什么慢”。profile 文件才是找根因的依据，而且必须配合 go tool pprof 读取，不能直接打开看文本。
立即学习“go语言免费学习笔记（深入）”；
-
go test -bench=MyFunc -cpuprofile=cpu.prof生成 CPU 采样数据，用go tool pprof cpu.prof进入交互模式，输入top看热点函数，web生成调用图 -
go test -bench=MyFunc -memprofile=mem.prof -benchmem同时开启内存统计和 profile 输出；注意：只有-benchmem才会让mem.prof包含对象分配位置信息 - 如果
pprof显示大量runtime.mallocgc占比高，说明问题不在算法逻辑，而在频繁小对象分配——这时该查逃逸分析（go build -gcflags="-m"） - profile 文件默认只记录当前包内代码，跨包调用若想看清，需确保被测依赖也未被内联（加
-gcflags="-l"禁用内联）
真正难的不是跑出数字，而是让两次 go test -bench 的对比有意义：环境隔离、GC 状态一致、warm-up 充分、profile 采集路径完整——这些细节漏掉一个，优化就变成玄学。
