Benchmark函数未执行的三大主因：文件名非xxx_test.go、函数名不以Benchmark开头、参数非*testing.B；运行需显式加-bench=.，且循环必须用b.N而非固定次数。
Go 基准测试函数如果没跑起来，大概率不是代码写错了，而是被 go test -bench 框架静默跳过了——不报错、不提示、输出里压根没你的函数。
为什么 Benchmark 函数根本没执行
最常见原因有三个，漏掉任意一个都会导致函数被跳过：
-
文件名不是xxx_test.go，或不在被测代码的同一包（比如放在main包或独立测试模块里） -
函数名不是以Benchmark开头的大驼峰命名，例如写成benchmarkXxx、BenchXxx或TestBenchmarkXxx都无效 -
参数类型不是*testing.B（必须带星号指针），写成testing.B、*testing.T或多加参数会直接编译失败或跳过
另外，运行命令必须显式带上 -bench=. 或具体正则，只跑 go test 或 go test -v 是不会触发任何 Benchmark 的。
for i := 0; i
这个循环结构不是“为了多跑几次”，而是基准框架控制采样节奏的核心机制：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
-
b.N是动态值，可能从 1 跳到 1000 万甚至上亿，目标是让整个循环耗时逼近-benchtime（默认 1 秒） - 手动写死
for i := 0; i 就等于绕过框架，<code>ns/op数值失去可比性和复现性 - 别在循环里写
if b.N == 1做初始化——每次运行b.N都不同，逻辑必然错乱 - 被测结果必须被消费，例如
_ = result或赋给全局变量，否则编译器可能直接优化掉整段逻辑
初始化开销必须用 b.ResetTimer() 隔离
setup 阶段（如 make([]byte, 1e6)、预热 json.Unmarshal、打开文件）如果不剥离，就会被摊进 ns/op，结果变成“初始化 + 执行”的混合值：
- 标准结构：先做所有 setup → 调用
b.ResetTimer()→ 再for i := 0; i -
b.ReportAllocs()必须放在b.ResetTimer()之后，否则内存统计包含 setup 阶段，allocs/op和B/op失真 - 如果主逻辑有副作用（比如往全局
map写数据），每次迭代前需重置状态，否则数据污染影响结果 - 对极慢操作（如 HTTP 请求），建议禁用连接复用：
&http.Client{Transport: &http.Transport{MaxIdleConns: 0}}，避免测的是连接池命中率
怎么对比两个实现的性能差异才靠谱
手动比两个 ns/op 数字很容易被系统噪声带偏，真正可靠的对比要靠统计工具：
- 用
-count=5重复运行五次，降低单次抖动干扰 - 同时观察
ns/op、allocs/op和B/op，避免只盯 CPU 忽略 GC 压力 - 保存基线：
go test -bench=^BenchmarkFoo$ -benchmem -count=5 | tee bench-old.txt - 改代码后跑新数据：
go test -bench=^BenchmarkFoo$ -benchmem -count=5 | tee bench-new.txt - 用
benchstat bench-old.txt bench-new.txt（需先go install golang.org/x/perf/cmd/benchstat@latest）做 Welch’s t-test，它会告诉你差异是否统计显著，而不是简单取平均
最容易被忽略的是 b.N 的动态性——它不是固定次数，而是框架根据采样实时调整的整数；你写的循环体里任何依赖 b.N 为常量的逻辑，都会在不同机器、不同 Go 版本、甚至同一次连续运行中失效。
