合法的 Benchmark 函数需命名为 BenchmarkXxx(testing.B)，置于 _test.go 文件中，且必须用 b.N 控制循环次数，不可自行固定循环次数。
Go 的性能测试不是加个 Benchmark 前缀就完事——它必须控制变量、规避编译器优化、用对计时方式，否则测出来的是假数据。
如何写一个合法的 Benchmark 函数
Go 测试框架只识别形如 BenchmarkXxx(*testing.B) 的函数，且必须放在 _test.go 文件里。函数体里必须调用 b.N 控制循环次数，不能自己写固定次数的 for 循环。
- 错误写法：
for i := 0; i —— <code>b.N被忽略，结果不可比 - 正确写法：
for i := 0; i —— Go 会自动调整 <code>b.N使总耗时稳定在约 1 秒 - 别在循环里做初始化（如 new map、alloc slice），应提至
b.ResetTimer()前，否则计入基准时间
benchmem 和 benchtime 怎么影响结果
go test -bench=. -benchmem 会额外报告内存分配次数和字节数，这对发现隐式拷贝、逃逸问题极关键；而 -benchtime=5s 可延长单个 benchmark 运行时间，减少统计抖动。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
-benchmem开启后，Allocs/op高通常意味着频繁堆分配，可能触发 GC 压力 -
-benchtime默认是 1s，短 benchmark（如纳秒级）容易因调度误差失真，建议设为3s或5s - 避免混用
-count=3和-benchtime：多次运行取平均虽好，但b.N每次重算，数值未必线性可叠加
为什么 runtime.GC() 有时必须手动调用
如果被测逻辑触发了 GC（比如大量小对象分配），而你又想排除 GC 时间干扰，就得在 b.ResetTimer() 前强制跑一次 GC，并等其完成。
- 不手动 GC：GC 时间可能被计入
ns/op，尤其在高分配率 benchmark 中偏差可达 20%+ - 推荐写法：
runtime.GC(); runtime.Gosched(); b.ResetTimer()——Gosched让 GC goroutine 有执行机会 - 注意：仅在明确怀疑 GC 干扰时加，日常 benchmark 不需要，否则反而引入调度开销
常见误判点：编译器优化让代码“消失”
Go 编译器会删掉未使用的计算结果。如果你 benchmark 一个纯计算函数但没用它的返回值，整个循环可能被优化为空操作。
- 典型现象：结果是
0 ns/op或异常低，Allocs/op = 0却明显该有计算 - 解决方法：用
blackhole抑制优化，例如result := compute(); blackhole(result) -
blackhole可定义为：var blackhole interface{}+blackhole = x，或直接用testing.B提供的b.ReportMetric辅助标记（但不推荐替代 blackhole）
真正难的不是写 benchmark，而是让每次运行都测量同一段逻辑——变量隔离、内存复位、逃逸控制、优化抑制，缺一不可。漏掉任意一环，数据就失去横向对比价值。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
