不靠谱——go test -bench 默认只统计执行时间，不记录内存分配；需显式加 -benchmem 才能获取 Allocs/op 和 B/op 数据，且依赖 runtime.ReadMemStats 快照差值计算。
用 go test -bench 测内存分配是否靠谱？
不靠谱——go test -bench 默认只统计执行时间，不记录内存分配行为。想测内存，必须显式启用分配统计，且需配合 -benchmem 标志。
-
-benchmem会开启每次基准测试中Allocs/op（每操作分配次数）和B/op（每操作字节数）的统计 - 它依赖运行时对
runtime.ReadMemStats的快照差值计算，仅适用于func BenchmarkXxx(*testing.B)形式 - 若函数内有逃逸到堆的变量（如切片扩容、闭包捕获大对象），
B/op会上升，但不会告诉你具体哪行触发了分配
如何定位具体哪行代码触发堆分配？
靠 go build -gcflags="-m -m" 查逃逸分析结果，这是最直接的方式。它能告诉你变量是否逃逸、为什么逃逸。
- 一级
-m显示基础逃逸决策；二级-m -m输出更详细原因（比如 “moved to heap: xxx” 或 “leaking param: yyy”） - 注意：必须用
go build编译源码（不是go run），且目标文件需可编译（不能含未使用变量等警告） - 常见诱因包括：返回局部切片/结构体指针、传入接口类型参数、调用
fmt.Sprintf、闭包引用外部大变量
go build -gcflags="-m -m" main.go
用 pprof 做运行时内存分配采样是否必要？
必要，尤其当基准测试结果异常或线上偶发 OOM 时。它能捕获真实分配热点，而非静态推断。
- 启动 HTTP 服务后访问
/debug/pprof/allocs可获取自程序启动以来的累计分配样本（注意：不是当前堆占用） - 用
go tool pprof http://localhost:6060/debug/pprof/allocs进入交互模式，执行top或web查看调用栈 - 若要观察短时高频分配，建议在关键逻辑前后手动调用
runtime.GC()清理历史噪音，再采样
写基准测试时怎么避免干扰内存测量？
最容易被忽略的是 *testing.B 的 b.ResetTimer() 和循环内变量复用问题。
立即学习“go语言免费学习笔记（深入）”；
- 所有初始化（如预分配切片、构造对象）必须放在
b.ResetTimer()之前，否则会被计入计时和分配统计 - 不要在
b.N循环内反复声明同名变量（如var x [1024]byte），虽然栈分配快，但可能掩盖真实堆行为；应改用make([]byte, 1024)显式控制 - 如果测试函数本身会修改全局状态（如缓存 map），记得在每次迭代后清理，否则后续迭代的分配量会失真
func BenchmarkCopySlice(b *testing.B) {
src := make([]byte, 1024)
b.ResetTimer()
for i := 0; i < b.N; i++ {
dst := make([]byte, len(src)) // 每次都新分配 → 计入 B/op
copy(dst, src)
}
}
实际压测中，B/op 数值波动超过 10% 就该怀疑 GC 干扰或数据局部性影响；这时候别只盯着数字，先用 -gcflags="-m -m" 看逃逸，再用 pprof 验证路径。 
