Go原生支持基准测试，需在_test.go文件中定义以Benchmark开头、接收*testing.B参数的函数；运行go test -bench=.执行全部，-bench=BenchmarkName指定单个，-benchmem查看内存分配，-benchtime调整时长；b.N为动态迭代次数，必须参与实际计算以防编译器优化。
用 go test -bench 启动基准测试
Go 原生支持基准测试，不需要额外依赖。只要在测试文件中写一个形如 BenchmarkXXX(*testing.B) 的函数，就能被 go test -bench 自动识别并执行。
注意：测试文件名必须以 _test.go 结尾，且函数名必须以 Benchmark 开头、接收 *testing.B 参数。
- 运行全部基准测试：
go test -bench=. - 只跑某个函数：
go test -bench=BenchmarkMapAccess - 加
-benchmem可同时查看内存分配次数和字节数 - 默认每个 benchmark 至少运行 1 秒；可通过
-benchtime=5s手动延长
写可比、不被编译器优化掉的基准函数
常见错误是操作太简单，被编译器内联或直接优化成常量，导致结果失真。比如 b.N 没参与计算、变量未使用、循环体为空。
*testing.B 的 b.N 是框架动态决定的迭代次数，必须把它作为循环上限，并确保每次迭代都产生实际效果（例如写入局部变量、调用非内联函数、触发内存分配）。
立即学习“go语言免费学习笔记（深入）”；
- ❌ 错误示例（会被优化）：
func BenchmarkBad(b *testing.B) { for i := 0; i < b.N; i++ { _ = 1 + 2 // 常量折叠，整段消失 } } - ✅ 正确示例（强制参与计算）：
func BenchmarkGood(b *testing.B) { var sum int for i := 0; i < b.N; i++ { sum += i } _ = sum // 防止整个循环被删 } - 如果测试 map 查找，记得先初始化好 map，不要把建 map 的开销算进每次迭代
对比多个实现时用相同输入和控制变量
要公平比较 A 和 B 两个函数（比如 strings.ReplaceAll vs 手写 strings.Builder 循环），必须保证它们处理完全相同的输入数据，且不因缓存、GC、预热不足引入偏差。
- 把输入数据（如字符串、切片）定义在
Benchmark函数外或b.ResetTimer()之前，避免重复初始化计入耗时 - 用
b.ReportAllocs()统一开启内存统计 - 必要时调用
runtime.GC()和debug.FreeOSMemory()（谨慎！仅用于排除 GC 干扰） - 多次运行取中位数更稳，但
go test -bench默认已做多次采样并输出平均值
识别真实瓶颈：别只看 ns/op
ns/op 看起来直观，但容易误导。尤其当函数分配大量内存时，B 值小但 allocs/op 高，可能在高并发下拖垮 GC。
典型陷阱：用 fmt.Sprintf 替代 strconv.Itoa，前者快 2 倍但多分配 3 次对象，长期运行反而更慢。
- 务必加
-benchmem，关注B/op和allocs/op - 用
-cpuprofile=cpu.pprof和-memprofile=mem.pprof导出分析文件，再用go tool pprof深挖热点 - 如果两个实现
ns/op相差不到 5%，基本可视为无差异；优先选可读性/维护性更好的那个
真正难的是让不同实现共享同一份输入状态又不互相污染——比如测试 channel 吞吐量时，发送端和接收端的 goroutine 调度顺序不可控，这时候单靠 go test -bench 得出的数字意义有限。
