Go基准测试需用BenchmarkXXX函数，接收*testing.B，循环体置于b.N内，调用b.ResetTimer()排除初始化开销，用b.ReportAllocs()统计内存，避免循环中做非目标操作。
怎么写一个能对比算法性能的 go test -bench 基准测试
Go 的基准测试不是“跑一次看耗时”，而是自动多次执行、取稳定均值，同时支持内存分配统计。关键在函数签名和命名规范：BenchmarkXXX 函数必须接收 *testing.B，且循环体要放在 b.N 控制的 for 中。
- 不把待测逻辑写在函数外或
b.ResetTimer()之前，否则初始化开销会被计入 - 如果算法依赖预热（比如 map 首次扩容），用
b.ReportAllocs()后手动跑一两轮预热，再调b.ResetTimer() - 避免在循环里做非目标操作：比如在 benchmark 循环里打印日志、调用
time.Now()、或创建新 goroutine —— 这些会污染结果 - 示例结构：
func BenchmarkSortSlice(b *testing.B) { data := make([]int, 1000) for i := range data { data[i] = rand.Intn(1000) } b.ResetTimer() for i := 0; i < b.N; i++ { sort.Ints(data) // 注意：这里需确保每次输入可复位，否则要用副本 } }
go test -benchmem 显示的 allocs/op 是什么，怎么看懂它
allocs/op 表示「每次操作触发的内存分配次数」，不是字节数；B/op 才是平均每次操作分配的字节数。这两个值共同反映算法的内存友好程度 —— 尤其对高频调用或 GC 敏感场景（如 HTTP handler）很关键。
- 如果
allocs/op是 0，不代表完全没分配，可能是编译器逃逸分析优化掉了临时变量（比如小数组栈上分配） - 若
B/op很高但allocs/op很低，说明单次分配很大（如切片底层数组扩容），要检查是否可复用缓冲区 - 对比不同实现时，务必保证输入规模一致（比如都用
make([]byte, 1024)），否则B/op失去可比性 - 用
go test -bench=. -benchmem -gcflags="-m"可看逃逸分析，确认哪些变量真的逃逸到堆上
为什么两个算法 benchmark 结果波动大，b.N 并不固定
Go 基准测试会动态调整 b.N —— 它先试跑少量次数估算单次耗时，再扩大 N 使总运行时间接近 1 秒（默认）。所以相同代码多次运行，b.N 可能差几倍，但 ns/op 应该收敛。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 如果
ns/op波动超过 ±5%，大概率是外部干扰：CPU 被抢占、后台进程活动、或待测逻辑本身含不确定因素（如依赖系统时间、随机数未 seed、或用了未锁的全局 map） - 避免在 benchmark 中调用
rand.Int()；改用固定种子的rand.New(rand.NewSource(0))实例 - Linux 下可用
taskset -c 0 go test -bench=.绑定单核，减少调度抖动 - 不要依赖单次
go test -bench=.输出下结论；至少跑 3 次，用benchstat工具比对（go install golang.org/x/perf/cmd/benchstat@latest）
想对比不同输入规模下的性能拐点，怎么组织 benchmark 函数
不能靠 if/else 切换规模，得写多个独立函数，用名字体现输入特征 —— Go 的 go test -bench= 支持正则匹配，方便筛选。
立即学习“go语言免费学习笔记（深入）”；
- 函数名按惯例带规模标识，如
BenchmarkSearch100、BenchmarkSearch10000，避免用BenchmarkSearchSmall这类模糊词 - 每个函数内生成对应规模数据，别复用全局变量（并发运行时会冲突）
- 如果算法有参数（比如哈希表负载因子），用闭包或子函数封装，但最终注册给
testing.B的仍是独立函数 - 示例：
func BenchmarkParseJSON1KB(b *testing.B) { runParseBenchmark(b, 1024) } func BenchmarkParseJSON100KB(b *testing.B) { runParseBenchmark(b, 102400) } func runParseBenchmark(b *testing.B, size int) { data := make([]byte, size) // ... fill with valid JSON b.ResetTimer() for i := 0; i < b.N; i++ { json.Unmarshal(data, &target) } }
内存分配行为随数据规模变化可能非线性，比如小 slice 栈分配、大 slice 必然堆分配 —— 这种拐点光看 100 和 10000 的 B/op 就能暴露出来，但得亲手试，没法靠推理猜准。
