Go 的 testing.B 无法在运行时获取实际耗时与内存统计值，只能通过 b.ReportAllocs() 启用自动统计、b.ResetTimer()/b.StopTimer() 控制计时范围，其余需手动计时或解析 go test -json 输出。
如何获取 testing.B 的实际耗时与内存统计值
Go 的 testing.B 本身不提供直接读取单次迭代耗时或总分配内存的公开字段，所有性能数据（如 BenchmarkXxx-8 1000000 1234 ns/op 56 B/op 2 allocs/op）都是在测试结束后由 testing 包内部计算并打印的。你无法在 Benchmark 函数执行过程中通过 b.N 或其他字段拿到「当前已跑完的 ns/op 值」——它根本还没算出来。
真正能用的只有两个钩子：b.ReportAllocs() 开启内存统计、b.SetBytes(n) 影响 B/op 的换算基准。其余数值必须靠自己计时 + 手动统计：
-
b.ResetTimer()和b.StopTimer()控制计时范围，避免 setup/teardown 被计入 - 用
time.Now(+
)time.Since()测量核心逻辑（仅适用于需要拆解阶段耗时的调试场景） - 内存分配数和字节数只能靠
b.ReportAllocs()启用后由运行时自动注入，不能手动赋值
)
testing.B 的 MemStats 不可用，别试图调 runtime.ReadMemStats 自己算
有人会想：我手动在 b.StartTimer() 前后调 runtime.ReadMemStats，再相减不就能算出本次 b.N 迭代的分配量？不行。原因有二：
- Go 的 GC 是并发的，
ReadMemStats返回的是全局快照，不是线程/协程局部值，两次调用之间可能被其他 goroutine 干扰 -
testing.B内部统计分配是基于runtime.MemStats的PauseTotalNs和NumGC等字段做差值，并结合b.N反推每 op，它还过滤了 runtime 自身开销；你手动测的只是粗略增量，结果对不上go test -bench输出
所以，如果真要验证内存行为，唯一可靠方式是开启 b.ReportAllocs()，然后信任 Go 测试框架的统计逻辑。
把 Benchmark 结果导出为结构化数据（JSON / CSV）的可行路径
Go 标准测试框架不支持直接导出 JSON。但你可以用 -json 参数让 go test 输出机器可读事件流，其中包含 benchmark 的最终结果行：
go test -bench=. -benchmem -json | grep '"Action":"output"' | grep -o '"Benchmark.*ns/op.*allocs/op"'
更稳妥的做法是写 wrapper 脚本解析标准输出。例如用 shell 提取关键字段：
go test -bench=BenchmarkMyFunc -benchmem 2>&1 | \
awk '/BenchmarkMyFunc/ {print $1, $3, $4, $5, $6}'
输出形如：BenchmarkMyFunc-8 1234567 89.2 ns/op 48 B/op 1 allocs/op。注意：go test 默认只对匹配的 benchmark 名执行，且 -bench=. 会跑全部，容易干扰目标结果。
如果你需要在代码里动态获取某次 benchmark 的统计值（比如做 A/B 对比），目前没有标准 API；只能靠 fork testing 包或改用第三方库如 github.com/acarl005/stripansi 配合正则提取 stdout。
为什么 b.N 会变化，以及它和最终 ns/op 的关系
b.N 不是你能设定的固定次数，而是 Go 自动调整的迭代数，目的是让单个 benchmark 至少运行 1 秒（可通过 -benchtime 修改）。框架会先试跑少量次数（如 1、10、100），根据耗时预估一个 N 使总时间接近目标，再正式跑。因此：
-
b.N在每次Run中可能不同，尤其当函数耗时波动大（如含 I/O 或 GC） -
ns/op = 总纳秒 / b.N，但「总纳秒」是去掉b.StopTimer()区间后的净计时，不是 wall clock - 如果函数内调用了
time.Sleep或阻塞系统调用，ns/op仍会计入，但此时数值已失去 CPU 耗时意义
真正影响结果稳定性的，往往是 GC 触发时机和 CPU 频率缩放——这些你控制不了，只能靠多次运行取中位数，或用 go test -count=5 -benchmem 配合外部工具分析离散度。
