go基准测试需严格遵循规范：函数名必须以benchmark开头、定义在_test.go文件中且参数为testing.b；预处理逻辑须置于b.resettimer()前；添加-benchmem才能观察内存分配；并发测试须用b.runparallel。
Go 的基准测试不是“测一下就完事”的玩具工具，它直接决定你能否真实捕捉函数级性能变化。不按规范写，Benchmark 函数会被忽略；不调用 b.ResetTimer()，初始化开销会混进结果；不加 -benchmem，内存分配暴增可能完全看不见。
为什么 go test -bench=. 找不到你的 Benchmark 函数
最常见原因是命名或位置不对。Go 测试框架只认特定模式，其他一律跳过。
- 函数名必须严格以
Benchmark开头，比如BenchmarkJSONMarshal，不能是benchmarkJSONMarshal或TestBenchmarkJSON - 必须定义在
*testing.B参数的函数里，签名错误（如用*testing.T）会导致编译通过但运行时静默跳过 - 文件必须以
_test.go结尾，且和被测代码在同一个包下；放在main包或独立测试包里，go test默认不加载 - 如果用了
go test -bench=BenchFoo但函数叫BenchmarkBar，自然匹配失败——名字要完全一致（支持正则，但别依赖）
如何避免 b.N 循环污染真实耗时
b.N 是框架自动调节的迭代次数，目的是让总执行时间稳定在约 1 秒。但如果你把数据构造、对象初始化写在循环里，这些操作会被重复执行并计入耗时，结果严重失真。
- 所有预处理逻辑（如生成测试数据、初始化结构体）必须放在
b.ResetTimer()调用之前 -
b.ResetTimer()后才开始循环，确保只计核心逻辑：比如json.Marshal调用本身，而不是反复make([]byte, 0)和构造 map - 切忌在循环内声明变量（尤其是大结构体），这会触发额外堆分配，干扰
ns/op和allocs/op的解读 - 若需多组输入，提前生成好 slice，循环中只做索引访问，避免 runtime 分配
怎么看懂 go test 输出里的关键数字
输出像 BenchmarkMapAccess-8 24567892 48.2 ns/op 0 B/op 0 allocs/op 这一行，每个字段都对应一个可操作指标。
-
24567892是实际执行次数（b.N），数值越大通常说明单次很快；如果只有几百次，说明函数太慢，要考虑是否误测了 IO 或阻塞操作 -
48.2 ns/op是核心指标，但要注意单位——纳秒级差异在微服务里可能就是 RT 毛刺来源；对比优化前后，看相对变化比绝对值更有意义 -
0 B/op和0 allocs/op表示零堆分配，这是高性能 Go 代码的典型特征；一旦出现非零值，就要检查是否有隐式逃逸（比如局部变量被闭包捕获、返回指针等） - 加
-benchmem才能看到后两项；没加的话，即使分配暴涨你也只能看到ns/op，极易误判
并发场景下必须用 b.RunParallel
普通 for i := 0; i 是串行执行，完全无法反映高并发下的真实表现，比如锁竞争、cache line false sharing、goroutine 调度开销等。
- 要用
b.RunParallel启动多个 goroutine 并发运行，例如：b.RunParallel(func(pb *testing.PB) { for pb.Next() { yourFunc() } }) - 它内部会自动分摊
b.N到各 worker，无需手动算并发数；但注意被测函数必须是线程安全的 - 结果中的
ns/op仍是“每次调用平均耗时”，但背后是并发压力下的统计值，更贴近线上流量模型 - 如果并发版比串行版
ns/op高很多，大概率存在锁瓶颈或共享资源争用，这时该去看 pprof 的 mutex profile 而不是继续调参数
真正难的不是写个 Benchmark 函数，而是让测试环境逼近生产负载——比如是否复用 sync.Pool、是否模拟真实请求大小、是否关闭 GC 干扰。这些细节不控制，再漂亮的数字也只是幻觉。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
