Go基准测试需严格遵循命名、文件、参数等规范，否则函数被静默跳过；b.N由框架动态调整以逼近-benchtime，默认1秒，循环必须用for i := 0; i
Go 基准测试不是“写个循环测一次”，
go test -bench必须控制执行节奏，否则ns/op数值不可比、不可复现。为什么 Benchmark 函数跑不起来
最常见的情况是函数根本没被识别——不报错、不提示、输出里压根没你的函数。
- 文件名必须是
xxx_test.go，且和被测代码同包（不能放在main包或独立测试包）- 函数名必须是
BenchmarkXxx（首字母大写驼峰），不能是benchmarkXxx、BenchXxx或TestBenchmarkXxx- 参数必须是
*testing.B（带星号指针），写成testing.B或*testing.T都会静默跳过- 漏掉
-bench=.参数：只运行go test或go test -v，Benchmark 函数完全不会执行怎么写一个真正有效的 Benchmark 循环
b.N是框架动态决定的整数，目标是让整个循环耗时接近-benchtime（默认 1 秒）。它可能从 1 跳到 100 万甚至上亿——这是正常行为。
- 必须用
for i := 0; i ，不能手动写死次数（如for i := 0; i ），否则绕过基准机制，ns/op失去意义- 别在循环里做
if b.N == 1初始化——每次运行b.N都不同，逻辑必然错乱- 被测逻辑结果必须被消费，比如赋给全局变量或
_ = result，否则编译器可能直接优化掉整段计算- 避免在循环内调用
fmt.Println、b.Log()或任何 I/O，输出被吞掉，还可能触发额外分配，污染B/op如何隔离初始化开销
初始化（如
make([]byte, 1e6)、json.Unmarshal预热、打开文件）如果不剥离，就会被摊进ns/op，导致结果是“初始化 + 执行”的混合值。
Golang Uber Dig下载使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 标准结构：先做所有 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重复运行五次，降低系统噪声干扰- 用
-benchmem同时观察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，判断差异是否统计显著最容易被忽略的是：不控制页缓存（如文件 I/O 测出来的是内核缓存速度）、不防编译器优化（返回值未消费导致整段逻辑被删）、以及把
b.ResetTimer()放错位置（比如放在循环内部或初始化之前）——这些都会让数字看起来很好，但完全不反映真实场景。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
