benchstat 不能直接判断性能变好或变坏，仅提供统计推断（如 p 值、置信区间），需结合效应量、业务场景与系统行为综合判断。
benchstat 能不能直接判断性能变好还是变坏
不能，benchstat 只做统计推断，不替你下结论。它输出的 p-value 和置信区间，本质是在问：“两次基准测试结果的差异，有多大可能是随机波动导致的？”——不是“快了 5% 就算优化成功”。
常见错误现象：benchstat old.txt new.txt 显示 geomean: -4.20% (p=0.032)，就立刻合代码；结果上线后 cpu profile 发现某路径毛刺翻倍。
- 必须配合
-delta-test=p（默认）或-delta-test=mean理解差异类型：前者检验中位数是否显著偏移，后者只看均值，对长尾噪声更敏感 - 单次
go test -bench运行默认只跑 1 秒，容易被 GC、调度抖动污染；建议用-benchtime=10s或更高，让benchstat有足够样本点拟合分布 -
benchstat对小幅度变化（
怎么准备 benchstat 能吃的输入文件
不是随便把 go test -bench 输出重定向就能喂给 benchstat。它要求每行是标准 BenchmarkXXX-8 1000000 1234 ns/op 格式，且同一组对比里，基准名、CPU 数（如 -8）必须严格一致。
使用场景：CI 中自动比对 PR 分支和 main 分支的性能基线。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 别用
go test -bench=. -benchmem > bench.out直接导出——开头的 go version、pkg path、pass 信息会污染解析，benchstat直接报错no benchmarks found - 正确做法是加
-json输出再转：go test -bench=. -benchmem -json | go run golang.org/x/perf/cmd/benchstat -；或用grep 'Benchmark' bench.out > clean.txt手动清洗 - 如果测试用了
-count=5，benchstat默认会取全部 5 次结果做 Welch’s t-test；但若某次因 OOM 被 kill，残留的BenchmarkXXX-8 0 0 ns/op会拉垮统计，得先awk '$3 != "0"' clean.txt过滤掉
为什么 benchstat 报 p=0.06 却说 “not significant”
因为默认显著性阈值是 α=0.05，p > 0.05 就不拒绝原假设（即“没证据表明有差异”），不等于“证明没差异”。这是统计学基本逻辑，但工程师常误读为“性能没变”。
性能 / 兼容性影响：在低延迟服务中，p=0.06 对应的实际延迟分布偏移可能已影响 P99；而在批处理场景，p=0.001 的微小改进可能毫无业务价值。
-
benchstat不输出效应量（effect size），光看 p 值会忽略差异大小。例如p=0.002, delta=-0.8%和p=0.04, delta=-8.2%，后者实际影响更大 - 用
-alpha=0.1可放宽阈值，但会提高假阳性率；适合早期探索性调优，不适合 release gate - 真正可信的结论需要满足：多次独立运行（不同机器、不同时间）、相同 Go 版本、关闭 CPU 频率调节（
echo performance | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor）
Go 1.21+ 的 benchmem 输出变动对 benchstat 的影响
Go 1.21 起，-benchmem 新增了 B/op 和 allocs/op 字段顺序调整，并在内存分配极少时显示 0 B/op 而非省略。这本身不影响 benchstat 解析，但容易掩盖真实问题。
常见错误现象：升级 Go 后 benchstat 显示内存分配下降 20%，结果线上 RSS 涨了——因为新版本 runtime 的 mallocgc 行为变化，B/op 降低但对象生命周期变长，导致堆驻留上升。
-
benchstat默认只比对ns/op，要纳入内存指标必须显式指定字段：benchstat -geomean -fields=ns/op,B/op,allocs/op old.txt new.txt - Go 1.22 开始，
runtime.MemStats的NextGC和HeapInuse更稳定，建议在 benchmark 函数里手动打点，用runtime.ReadMemStats记录，再和benchstat结果交叉验证 - 跨 Go 版本对比必须谨慎：1.20 → 1.21 的逃逸分析改进会让很多
[]byte不再堆分配，B/op下降是编译器进步，不是你的代码变好
性能数据的可信度不取决于 benchstat 是否报绿，而取决于你有没有控制住变量、理解指标背后的 runtime 行为、以及敢不敢把 p=0.07 的结果扔进生产环境跑一周真实流量。
