B/op 和 allocs/op 是 Go 基准测试中衡量内存占用的核心指标，分别表示每次操作平均分配的字节数和堆分配次数；添加 -benchmem 参数或调用 b.ReportAllocs() 可启用统计。
直接看 B/op 和 allocs/op 这两项，它们就是 Go 基准测试中内存占用的核心指标——前者是每次操作平均分配的字节数，后者是每次操作发生的堆分配次数。数值越低，内存压力越小，GC 越轻松。
怎么让 benchmark 输出内存数据？
只需在命令里加 -benchmem，不用改代码；或者在函数里显式调用 b.ReportAllocs()（更推荐，能确保统计开启）。
-
-benchmem是最简方式：运行go test -bench=^BenchmarkParse$ -benchmem，输出自动带B/op和allocs/op -
b.ReportAllocs()必须写在for i := 0; i 循环之前（哪怕在 <code>b.ResetTimer()后也行），否则可能漏统计 - 不加这两者中的任一，结果里就只有
ns/op，看不到内存信息
为什么 allocs/op 比 B/op 更值得关注？
因为一次分配哪怕只分 8 字节，也会触发堆上对象创建、GC 标记、逃逸分析路径变化——它直接反映“有多少变量被迫上堆”。而 B/op 高，可能是单次大分配（比如读一个 1MB 文件），未必高频；allocs/op 高，往往意味着循环里反复 make、append、字符串转切片等。
Comprehensive Three.js 3D graphics reference
下载
详细的 Three.js 3D 图形参考，涵盖场景设置、相机、几何体、材质、光照、动画、控制器、加载器、数学工具和调试。
- 常见高
allocs/op场景：strings.Repeat、fmt.Sprintf、string([]byte)、未预设容量的make([]T, 0)、闭包捕获局部变量 - 注意：编译器可能内联或消除某些分配，所以别只信 benchmark 数值，要用
go tool compile -gcflags="-m -l"看逃逸分析确认 - 如果
allocs/op是 0，不代表没分配——栈分配不计入，只统计堆分配
如何定位到底是哪行在疯狂分配？
靠 -memprofile + pprof，不能只看总量。
- 生成 profile：
go test -bench=^BenchmarkParse$ -memprofile=mem.out - 分析：
go tool pprof mem.out，然后输入top看分配最多的函数，list ParseJSON查具体行号，web看调用图（需装 graphviz） - 关键技巧：在 benchmark 开头加
runtime.GC()，避免前序测试残留影响本次内存采样 - 容易踩坑：profile 文件只记录堆分配，且是采样数据；若
b.N太小（比如默认几万次），分配事件太少，pprof 可能无法有效聚类
真正难的不是跑出数字，而是理解「为什么这行会逃逸」「那个 allocs/op 是来自扩容还是新对象」——得把 -gcflags="-m" 的输出和 pprof 的调用栈对上，才能下准手。否则优化只是碰运气。
