必须显式启用-benchmem和b.reportallocs()才能测出内存分配；b/op表示每次调用平均堆分配字节数，allocs/op表示每次调用堆分配次数；需用pprof定位具体分配行，优化时优先预分配、sync.pool复用及避免逃逸。
怎么让 Benchmark 真正测出内存分配？
不加 -benchmem 或不调用 b.ReportAllocs()，go test -bench 默认只输出耗时（ns/op），B/op 和 allocs/op 两列直接消失——你根本看不到内存行为。
- 必须显式启用：在测试函数开头写
b.ReportAllocs()（Go 1.8+ 虽默认开启，但不写容易被忽略或误关） - 命令行必须带
-benchmem：如go test -bench=Sum -benchmem -
b.ResetTimer()要放在初始化之后、循环之前，否则把预分配、解析等准备时间也算进指标里，数据失真
B/op 和 allocs/op 到底在说啥？
B/op 是每次调用平均在堆上分配的字节数；allocs/op 是每次调用触发的堆分配次数。两者都为 0 不代表没开销——栈上分配不计入，但逃逸分析可能已悄悄把你小结构体推上堆。
-
allocs/op更关键：1 次分配可能 1KB，10 次分配可能总共才 100B，但 GC 要扫 10 个对象头，压力翻倍 - 字符串转切片：
[]byte(s)必然触发一次堆分配；unsafe.Slice(unsafe.StringData(s), len(s))（Go 1.20+）可绕过，但仅限只读且生命周期可控场景 - 闭包捕获大 struct？哪怕只读一个字段，整个 struct 都可能逃逸——用
go build -gcflags="-m -l"看逃逸详情
怎么定位谁在偷偷 malloc？
光看总量不够，得知道哪一行代码在分配。这时候不能只靠 -benchmem 输出，得上 pprof。
- 生成内存 profile：
go test -bench=ParseJSON -memprofile=mem.out -memprofilerate=1（-memprofilerate=1强制记录每次分配） - 分析：
go tool pprof mem.out→ 输入top看前几行，或web生成调用图 - 常见高分配源头：
fmt.Sprintf、循环里反复make([]T, n)、json.Unmarshal中未复用的map或struct、strings.Builder忘记Reset()
哪些优化真正有效？别白忙
预分配、sync.Pool、避免接口隐式装箱，这些不是“听起来对”，而是有明确数字支撑的。
立即学习“go语言免费学习笔记（深入）”；
- slice：用
make([]int, 0, n)替代[]int{}，尤其当n可预估时，allocs/op常从 N 次降到 1 次 -
sync.Pool：适合中大型临时对象（如 256B+ 的 buffer），小对象（如int、string）用它反而增加调度开销 - map：用
make(map[string]int, n)预设桶数，减少 rehash；但若n过度估计，会浪费内存，得权衡 - 别迷信
unsafe：绕过分配的前提是确定生命周期——比如 HTTP handler 里把请求 body 字节切片转成 string 供只读解析？可以；但存到全局 map 里？不行
最常被忽略的一点：基准测试里没用 _ = result 或类似方式防止编译器优化掉计算，会导致 allocs/op 显示为 0——不是没分配，是压根没跑那行代码。
