-4 表示 GOMAXPROCS=4，即基准测试在最多 4 个 OS 线程的调度环境下运行，该值由 testing 包读取并追加至函数名后，影响并行行为与并发度，跨环境比对前须确保一致。
Go benchmark 输出中 BenchmarkXXX-4 后缀的含义
这个 -4 不是随意加的，它表示当前基准测试运行在 GOMAXPROCS=4 的调度环境下，即最多使用 4 个 OS 线程来执行 goroutine。Go 的 testing 包会在测试开始前读取当前 GOMAXPROCS 值，并将其追加到基准函数名后，方便区分不同并发配置下的性能表现。
如果你手动设置了 GOMAXPROCS（比如 runtime.GOMAXPROCS(2)），或通过环境变量 GOMAXPROCS=1 启动测试，后缀就会变成 -2 或 -1。这直接影响并行 b.RunParallel 的行为和单次 b.N 迭代的实际并发度。
- 不修改默认值时，
-4在多数现代机器上很常见，但不代表 CPU 核心数，仅反映当前调度器线程上限 - 若报告中出现
-1，往往意味着测试被限制为单线程，可能掩盖真实并发瓶颈 - 跨环境比对基准数据前，务必确认
GOMAXPROCS一致，否则ns/op差异可能由调度干扰导致，而非代码本身
go test -bench 默认只显示“显著提升/退化”的结果？
不是默认隐藏，而是 go test -bench 本身不做过滤 —— 它输出所有匹配的基准函数，但默认不显示每次运行的原始 BenchmarkResult 字段（如 MemAllocsPerOp、BytesPerOp）。真正造成“只看到部分结果”的，通常是用了 -benchmem 却没注意输出格式，或误以为未达阈值就不报。
Go 的基准测试不会跳过任何标记为 Benchmark* 的函数，只要名字匹配 -bench 正则就会执行。所谓“未显示”，常见于：
立即学习“go语言免费学习笔记（深入）”；
- 函数未调用
b.ReportAllocs()，且未加-benchmem，则内存分配列完全不出现 -
b.N被自动调整到极小值（如1）仍无法在 1 秒内完成，测试会提前终止并标记为--- BENCH: BenchmarkXXX，但无最终数值 —— 此时需检查逻辑是否阻塞（如死循环、同步 I/O） - 使用
-bench=. -run=^$可强制跑所有基准且不执行单元测试，避免干扰
如何从 BenchmarkResult 结构体提取关键指标
testing.BenchmarkResult 是 go test 内部使用的结构体，**不导出、不可直接 import**。你无法在测试代码里声明 var r testing.BenchmarkResult。所有“解析”动作都发生在测试运行结束后，由 go test 主程序汇总输出，或通过 -json 输出结构化数据供外部工具消费。
真正可操作的方式只有两种：
- 用
go test -bench=. -benchmem -json，输出每轮测试的完整 JSON，包含"N": 1000000, "T": 123456789, "AllocsPerOp": 2, "BytesPerOp": 16等字段 —— 这是唯一能稳定获取BenchmarkResult级别数据的途径 - 在
BenchmarkXXX函数内调用b.ReportMetric(123.4, "MB/s")注入自定义指标，它会出现在最终文本输出末尾，也会被-json收集 - 不要试图用反射或
unsafe读取b的私有字段 ——testing.B没有公开的 result 获取接口，且内部结构随版本变化，极不稳定
go test -bench=BenchmarkMapAccess -benchmem -json | jq 'select(.Action == "benchmark")'
为什么 ns/op 波动大，且多次运行结果不一致？
ns/op 是单次操作平均耗时，但它基于 b.N 次循环总耗时计算：T / N。而 b.N 是 Go 自动调整的：先试 1，若总耗时 N 值不同，采样基数就不同。
更关键的是，Go 基准测试**不做预热、不隔离 GC、不绑定 CPU 核心**。一次运行中可能发生多次 GC、系统中断、CPU 频率升降，都会污染 T。所以单次 go test -bench 输出的 ns/op 只具参考性。
- 必须用
-count=5运行至少 5 轮，再看中位数或标准差 ——go test -bench=. -count=5 -benchtime=3s更可靠 - 加
-gcflags="-l"禁用内联可能暴露真实调用开销，但会改变代码路径，慎用于对比 - 真要压测吞吐，应改用
b.RunParallel+ 外部监控（如/proc/stat），而不是依赖单个ns/op
最常被忽略的一点：ns/op 数值本身没有绝对意义，它只在相同环境、相同 -benchtime、相同 GOMAXPROCS 下，对同一代码的前后变更才有可比性。拿 A 机器的 120 ns/op 和 B 机器的 95 ns/op 直接对比，基本无效。
