必须同时使用 -benchmem 参数和 b.ReportAllocs() 调用，才能让 go test -bench 输出 B/op 和 allocs/op；二者缺一不可。
怎么让 go test -bench 输出 B/op 和 allocs/op？
不加任何参数时，go test -bench=. 只显示 ns/op，**完全不统计内存**。必须显式启用才能看到 B/op（每次操作平均分配字节数）和 allocs/op（每次操作堆分配次数）。有两种等效方式，但推荐都用：
-
-benchmem命令行参数：最简，例如go test -bench=BenchmarkParse -benchmem - 在 Benchmark 函数开头调用
b.ReportAllocs()：意图明确，避免 CI 或自定义流程漏掉 flag；且必须放在b.ResetTimer()之前或之后（不能在循环里）
只加 -benchmem 但没写 b.ReportAllocs()，旧版 Go 可能不生效；只写函数调用却不加 flag，输出仍无内存列——两者缺一不可。
为什么 allocs/op 比 B/op 更值得盯死？
allocs/op 直接对应 GC 压力和缓存局部性，而 B/op 只是总量。一次 8 字节的分配，和一次 1MB 的分配，在 B/op 上差了 12.5 万倍，但在 GC 眼里都是“一个新对象”，都要标记、扫描、可能触发 STW。
- 10
allocs/op, 200B/op→ 10 次 GC 开销，大概率来自循环内反复make、append、string([]byte) - 1
allocs/op, 500B/op→ 1 次大块分配，比如读整个文件，压力小得多 - 常见高
allocs/op场景：fmt.Sprintf、未预容量的make([]T, 0)、闭包捕获局部变量、strings.Repeat
allocs/op 是逃逸分析的落地指标：它高，说明很多本该在栈上的变量被“逼”上了堆。
如何定位到底是哪一行在疯狂分配？
光看总量没用，得查调用栈。靠 -memprofile + pprof，不是靠猜：
- 先加
runtime.GC()在 benchmark 开头，清掉前序残留，避免干扰采样 - 生成 profile：
go test -bench=BenchmarkParse -benchmem -memprofile=mem.out - 分析：
go tool pprof mem.out，然后输入top看分配最多的函数，list ParseJSON查具体行号，web看调用图（需装graphviz） - 注意：
-memprofile只记录堆分配，且是采样数据；若b.N太小（如默认几万次），分配事件太少，pprof可能聚类失败
真正难的不是跑出数字，而是把 go build -gcflags="-m -l" 的逃逸分析输出，和 pprof 的调用栈对上——否则优化只是碰运气。
哪些写法会悄悄抬高 allocs/op？
有些分配看着 innocuous，实则高频触发。典型例子：
-
string([]byte)和[]byte(string)：每次调用都新分配底层数组，哪怕只读也逃不掉 - 循环内
sb := strings.Builder{}：Builder 本身小，但内部 buffer 默认从 0 开始扩容，第一次WriteString就 alloc - 未预估容量的
append：比如res := []int{}然后循环append(res, x)，扩容路径会多次分配 - 闭包捕获大结构体：哪怕只读一个字段，整个结构体也可能逃逸到堆
优化不是追求零分配，而是聚焦高频路径，压低 allocs/op，控制对象生命周期。比如用 sync.Pool 复用 Builder 或 buffer，或改用 make([]int, 0, expectedCap) 预分配。
