go 的 go test -bench 默认动态调整 b.n 使总运行约1秒，ns/op 是稳定均值；benchmark 函数须同包、_test.go 文件、benchmark 开头、签名正确；需显式加 -benchmem、-count=5、-cpu=1 等参数确保可复现；b.resettimer() 必须用于切割初始化与测量。
Go 的 go test -bench 不是“跑一次看耗时”，它默认会动态调整 b.N 直到总运行时间稳定在 1 秒左右——这意味着你看到的 ns/op 是统计意义上可复现的均值，但前提是环境没被干扰、代码没被优化掉、初始化开销没混进去。
benchmark 文件必须和被测代码同包且以 _test.go 结尾
很多人卡在第一步：函数写了、命令也跑了，但 go test -bench=. 没输出。根本原因是 Go 测试框架只扫描当前包下、文件名匹配 *_test.go 的源码，并且只执行函数名以 Benchmark 开头、签名为 func(b *testing.B) 的函数。
- 不能把
BenchmarkFoo放在main.go或任意非_test.go文件里 - 不能跨包调用被测函数却不 import 对应包（比如被测函数在
pkg/validator，测试文件却在cmd/下） - 如果被测函数是 unexported（小写开头），测试文件必须和它在同一包内，否则无法访问
go test -bench 命令参数必须硬编码进 CI 或本地脚本
靠记忆敲命令容易漏关键参数，导致结果不可比。比如不加 -benchmem 就看不到内存分配，不加 -count=5 就只有单次测量，而单次 ns/op 波动可能超过 ±15%。
在 Go 中使用 google/wire 实现编译时依赖注入——wire.NewSet、wire.Build、wire.Bind（接口→实现）、wire.Struct、wire.Value、wire.Interface
-
-bench=.运行全部 benchmark，但建议缩窄范围，如-bench=BenchmarkValid，避免无关函数干扰 warmup -
-benchmem必须显式加——它开启内存统计，输出B/op和allocs/op，这对识别隐式分配很关键 -
-count=5推荐最低值，go test会对每次运行单独计时再取中位数，比单次更稳 -
-cpu=1在对比 CPU 敏感型操作（如 map 查找、json 解析）时建议固定，避免多 P 调度抖动影响ns/op
b.ResetTimer() 不是可选，而是基准线切割点
所有初始化逻辑（构造输入数据、预热缓存、创建对象）都必须放在 b.ResetTimer() 之前；所有实际被测逻辑必须在它之后、for i := 0; i 循环内。否则，初始化耗时会被摊到每次迭代里，<code>ns/op 就失真了。
- 错误写法：
m := make(map[int]int); b.ResetTimer(); for ... { m[i] = i }—— map 构造开销没被排除 - 正确写法：
m := make(map[int]int); for i := 0; i - 如果初始化本身也要测（比如 map 构建性能），那就另写一个
BenchmarkMakeMap，不要混在一起
防止编译器优化抹掉真实耗时
Go 编译器发现 result := Valid([]byte(str)) 后 result 没被用，就会直接删掉整行调用——你看到的 1.2 ns/op 实际是空循环。
- 最简方案：
_ = Valid([]byte(str))，强制保留调用副作用 - 更稳妥方案：声明变量并赋值后丢弃，如
res := Valid([]byte(str)); _ = res - 配合
b.ReportAllocs()一起用——如果allocs/op是 0，大概率函数被优化掉了 - 别信
println或fmt.Println，它们会引入 I/O 开销，污染ns/op
真正难的不是写对 BenchmarkXxx 函数，而是让每次 go test -bench 输出的数字能横向对比、纵向复现。环境噪音、编译优化、GC 干扰、P 数量浮动——这些全得靠参数硬化+代码结构约束来压住。漏掉任意一环，ns/op 就只是个数字，不是性能证据。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
