b.ReportAllocs() 不显示内存统计是因为基准测试未触发堆分配，如仅操作栈变量、复用切片或使用 sync.Pool；需在 b.Run 或 b.ResetTimer 后、循环前调用才生效。
为什么 b.ReportAllocs() 有时不显示内存统计
调用 b.ReportAllocs() 后没看到 Benchmem 输出，大概率是因为基准测试函数没真正触发堆分配——比如只操作栈变量、复用已分配的切片、或底层用了 sync.Pool。Go 的基准测试只统计显式调用 new、make（非小切片优化场景）、或间接导致堆分配的代码路径。
- 必须在
b.Run或b.ResetTimer之后、循环体之前调用b.ReportAllocs()，否则无效 - 如果被测逻辑里有
append且容量足够，不会触发新分配，AllocsPerOp就是 0 - Go 1.21+ 对小对象（b.ReportAllocs() 就捕获不到
b.ReportAllocs() 统计的是哪些分配
它只统计当前 *testing.B 实例下、从调用该方法开始到基准函数结束期间，所有由 runtime.mallocgc 触发的堆内存分配，不含栈分配、mmap 映射、CGO 分配，也不含测试框架自身开销（如 b.N 循环管理）。
- 统计单位是「每次操作（per-op）」，即
b.N次迭代的平均值，不是总和 - 输出中的
AllocsPerOp是分配次数，AllocedBytesPerOp是字节数，二者不必然成正比（比如一次make([]byte, 1024)和一千次make([]int, 1)分配次数差 1000 倍 - 如果函数内调用
runtime.GC()，会干扰统计，导致 AllocsPerOp 异常偏高（GC 前的存活对象被重复计数）
和 -benchmem 标志的关系
b.ReportAllocs() 是运行时开关，-benchmem 是命令行全局开关；两者开启任意一个，都会启用内存统计，但行为略有差异。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 只加
-benchmem：所有基准函数都强制报告内存，不管是否调用b.ReportAllocs() - 只调
b.ReportAllocs()：仅该函数生效，其他b.Run子基准默认不统计 - 同时存在时，以
b.ReportAllocs()为准，且它还能在子基准中单独控制，比如：func BenchmarkBigStruct(b *testing.B) { b.Run("with pool", func(b *testing.B) { b.ReportAllocs() for i := 0; i < b.N; i++ { // ... } }) b.Run("no pool", func(b *testing.B) { // 不调 ReportAllocs → 无内存数据 }) }
容易误读的典型输出和排查建议
看到 56 B/op 1 allocs/op 就以为“只分配了一次”，其实可能隐藏了多次小分配合并上报，或者逃逸分析失败导致意外堆分配。
立即学习“go语言免费学习笔记（深入）”；
- 用
go build -gcflags="-m -m"看关键变量是否逃逸，确认分配是否合理 - 对比
go test -bench=. -benchmem -benchtime=1x和默认时间，避免因b.N过小导致统计噪声（如b.N=1时 AllocsPerOp 容易失真） - 如果
AllocsPerOp是小数（如0.8），说明部分迭代没分配，部分迭代分配了，需检查逻辑分支是否条件触发分配
内存分配统计依赖运行时采样和逃逸分析结果，同一段代码在不同 Go 版本、不同构建参数（如 -ldflags="-s -w"）下可能表现不一致，别只盯一个数字。
