需调用 b.ReportAllocs() 或加 -benchmem 参数启用内存统计；输出中“B/op”和“allocs/op”表示每次操作的堆分配字节数与次数，仅统计堆分配；预处理逻辑应放在 b.ResetTimer() 前以排除干扰。

怎么开启内存分配统计

在 Go 基准测试中，内存分配数据默认不显示，必须显式启用。最直接的方式是在 BenchmarkXxx 函数开头调用 b.ReportAllocs() —— 这会告诉测试框架：请记录每次循环中堆上的字节分配量和分配次数。

你也可以不写这行，改用命令行参数 -benchmem（例如 go test -bench=. -benchmem），效果等价。但建议始终显式写上 b.ReportAllocs()，因为：

• 它让意图更明确，避免依赖外部 flag 忘记开启
• 某些 CI 或自定义测试流程可能未传 -benchmem
• 新版 Go 虽默认开启部分统计，但 b.ReportAllocs() 是唯一能确保采样生效的 API

怎么看输出里的内存指标

运行后你会看到类似这样的结果：

BenchmarkConcat-8    5000000    218 ns/op    160 B/op    4 allocs/op

其中两个关键字段是：

• 160 B/op：每次操作平均分配了 160 字节堆内存（不是栈，也不是总内存占用）
• 4 allocs/op：每次操作发生了 4 次堆内存分配（new、make、隐式逃逸都算）

注意：B/op 和 allocs/op 都是采样均值，来自 runtime.ReadMemStats 在循环前后两次快照的差值。它们只反映「堆分配」，栈上分配完全不计入 —— 所以如果看到 0 B/op 0 allocs/op，不等于没开销，可能是变量成功留在栈上（可配合 go build -gcflags="-m" 验证逃逸）。

如何排除初始化干扰，只测核心逻辑

很多基准测试会预先构造输入数据（比如 data := make([]byte, 1024)），如果不加控制，这部分分配也会被计入 B/op 和 allocs/op，导致结果失真。

正确做法是：

• 把准备逻辑写在 b.N 循环之前
• 调用 b.ResetTimer() 重置计时器（同时也会重置内存统计起点）
• 再调用 b.ReportAllocs()（推荐放在 ResetTimer 之后，确保统计范围精准）

示例：

func BenchmarkProcessData(b *testing.B) {
    data := make([]byte, 1024) // 预分配，不计入统计
    b.ResetTimer()
    b.ReportAllocs()
    for i := 0; i < b.N; i++ {
        process(data) // 只统计这一行的分配
    }
}

容易被忽略的坑：编译器优化和逃逸分析

即使你写了 b.ReportAllocs()，也可能看到 0 allocs/op，但这不代表代码真的零分配——常见原因有：

• result := make([]int, 100) 被逃逸分析判定为栈分配（小切片 + 无外泄地址）→ 不计入统计
• 返回值没被使用，编译器直接优化掉整条语句（如 make([]int, 100) 后没赋值也没读取）→ 分配被删，B/op 变成 0
• 闭包捕获局部变量，导致整个结构体逃逸到堆 → allocs/op 突然变高，但你可能没意识到是闭包惹的祸

应对方法：

• 用 _ = result 强制保留结果，防止死代码消除
• 加 -gcflags="-m -l" 查看逃逸详情（-l 禁用内联，让分析更准）
• 对比不同输入规模下的 B/op 是否线性增长，判断是否存在隐式扩容（比如 slice append 未预分配）

真正难的不是跑出数字，而是看懂为什么是这个数字 —— 尤其当 allocs/op 从 1 跳到 5，而你只改了一行 append 时。