go基准测试必须由go test -bench框架控制执行节奏，函数名需为benchmarkxxx、参数为*testing.b、文件为xxx_test.go且同包，循环必须用b.n而非固定次数，初始化开销需用b.resettimer()隔离，性能对比应使用benchstat进行统计显著性分析。
Go 基准测试不是“写个循环测一次”，而是必须让 go test -bench 框架控制执行节奏，否则 ns/op 数值完全不可比、不可复现。
func BenchmarkXxx(b *testing.B) 为什么必须这么写
函数名、签名、文件位置三者缺一不可：名字必须是 BenchmarkXxx（首字母大写驼峰），参数必须是 *testing.B（带星号指针），文件必须叫 xxx_test.go 且和被测代码同包。漏掉任意一个，go test -bench=. 就会静默跳过——不报错、不提示、输出里压根没你的函数。
常见无效写法：benchmarkFib（小写开头）、Benchmarkfib（驼峰错误）、TestBenchmarkFib（混用 Test 前缀）、func BenchmarkXxx(b testing.B)（漏指针）。
- 放在
main.go或普通.go文件里？不会被加载 - 包名不一致（比如基准测试在
main包，被测逻辑在utils包）？编译失败或无法调用 - 用了
b.Log()或fmt.Println()？输出被吞掉，还可能触发额外分配，污染B/op
for i := 0; i
b.N 是框架动态决定的整数，目标是让整个循环耗时接近 -benchtime（默认 1 秒）。它可能从 1 跳到 100 万甚至上亿——这是正常行为，说明框架在努力压出稳定样本。你手动写死 for i := 0; i ，等于绕过整个基准机制，<code>ns/op 失去意义。
- 极快函数（如加法）
b.N可能飙到千万级；极慢函数（如 HTTP 请求）可能只跑几次就被截断——都由框架自动适配 - 别在循环里做
if b.N == 1初始化——每次运行b.N都不同，逻辑必然错乱 - 被测逻辑结果必须被消费，比如赋给
_或全局变量，否则编译器可能直接优化掉整段计算
b.ResetTimer() 和 b.ReportAllocs() 必须成对出现
初始化开销（如 make([]byte, 1e6)、json.Marshal 预热、打开文件）如果不剥离，就会被摊进 ns/op，导致结果是“初始化 + 执行”的混合值。尤其当初始化耗时远超主逻辑时，数字毫无参考性。
- 标准结构：先做所有 setup → 调用
b.ResetTimer()→ 再for i := 0; i 执行主逻辑 -
b.ReportAllocs()要放在b.ResetTimer()之后，否则内存统计含 setup 阶段，allocs/op和B/op失真 - 如果主逻辑有副作用（比如修改全局 map），每次迭代前需重置状态，且重置代码要放在
b.StopTimer()和b.StartTimer()之间，避免计入计时
怎么对比两个实现的性能差异
单独跑两次 go test -bench=. 然后肉眼比数字，基本等于靠运气下结论。系统噪声、后台进程、GC 抖动都会让单次结果波动剧烈。
- 正确流程：
go test -bench=BenchmarkOld -benchmem -count=5 | tee old.txt→ 改代码 →go test -bench=BenchmarkNew -benchmem -count=5 | tee new.txt→benchstat old.txt new.txt -
benchstat不是比较平均值，而是用 Welch’s t-test 判断差异是否统计显著，并给出置信区间（比如 “快了 12.3% ± 1.8%”） - 想横向对比多个策略（如不同缓存大小、算法分支），用
b.Run("name", func(b *testing.B){...})，每个子项独立收敛b.N，结果清晰可比
最常被忽略的点：很多人以为 b.N 是“我该跑多少次”，其实它是“框架说这次该跑多少次”——你唯一能做的，是确保每次迭代都执行相同路径、结果被消费、初始化被隔离。其余全部交给框架。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
