该写 Benchmark 而不是 Test 时，是为回答“快不快”“是否变慢”“谁更省资源”等性能问题，而非验证结果正确性；二者目的不同，不可混用。
什么时候该写 Benchmark 而不是 Test
当你需要回答“这个函数快不快”“改完之后变慢了没”“A 实现比 B 实现省多少内存”，而不是“结果对不对”时，就该用基准测试。单元测试验证逻辑正确性，基准测试验证性能表现——两者目的完全不同，混用会导致误判。
- 算法选型：比如比较
strings.Builder和+=拼接 10KB 字符串的耗时与 allocs/op - 重构验证：上线前跑一次
go test -bench=.，确认ns/op没上涨 20% 以上 - 库作者提供性能承诺：如 “
json.Unmarshal在 1KB 小对象下 ≤ 500 ns/op” - 高并发路径压测前摸底：先在单 goroutine 下测清基础延迟，再用
b.RunParallel加并发
go test -bench=. 默认行为有哪些坑
直接跑 go test -bench=. 看似简单，但默认设置容易掩盖真实问题。比如 b.N 可能太小导致抖动大，或初始化代码被计入计时，又或者内存分配被忽略。
- 不加
-benchmem：看不到allocs/op和B/op，等于只看一半性能——尤其对 GC 敏感服务，漏掉内存指标可能上线后 OOM - 不设
-benchtime（默认 1 秒）：短函数（如int运算）可能只跑几百万次，统计波动大；建议至少-benchtime=5s - 忘记
b.ResetTimer()：若初始化部分（如构造大 slice、预热 map）写在循环外但耗时显著，必须手动重置，否则测的是“初始化 + 执行”总时间 - 未控制 CPU 数量：
BenchmarkX-8表示用了 8 核，但你的生产环境可能是 4 核；可用-cpu=4锁定，避免横向对比失真
怎么写一个不骗自己的 Benchmark 函数
核心原则是：只测你想测的那行代码，其他都剥离。常见错误是把变量声明、预分配、甚至 fmt.Println 塞进循环里，导致结果反映的是调试开销而非真实性能。
- 输入数据尽量复用：用闭包或全局变量准备好输入，避免每次循环都 new 或 copy
- 输出不逃逸：如果函数返回 string/slice，但你并不关心内容，用
_ = f(input)，防止编译器优化掉整条调用 - 避免隐式分配：比如
fmt.Sprintf必然分配内存，换成strconv.Itoa更干净 - 并发测试用
b.RunParallel：它会自动分发 goroutine，但注意被测函数必须是线程安全的，且不能依赖共享状态
示例中错写：for i := 0; i —— 这里每次循环都 <code>make，测的是内存分配器速度，不是你的算法。
结果里的 ns/op 和 allocs/op 怎么看才靠谱
ns/op 不是绝对时间，而是相对标尺；allocs/op 比想象中更关键——一次分配可能触发 GC，拖慢后续所有操作。别只盯着数字大小，要看变化趋势和场景匹配度。
- 对比必须同环境：同一台机器、关闭后台程序、禁用笔记本节能模式；虚拟机或云主机因资源争抢，
ns/op波动常超 30% - 关注倍数而非绝对值：从 120 ns/op → 90 ns/op 是 25% 提升，可信；但从 0.35 ns/op → 0.28 ns/op（看似提升 20%）很可能只是噪声，因为已逼近 CPU 指令周期
-
allocs/op > 0且B/op高：说明有隐式堆分配，优先检查是否用了interface{}、闭包捕获大变量、或未预分配 slice - 多次运行取中位数：用
-count=5跑 5 轮，再用benchstat分析，比单次结果可靠得多
最常被忽略的一点：基准测试永远只能告诉你“这段代码在当前输入规模下的表现”，而不是“它在线上千万 QPS 下会不会卡住”。真要模拟线上，得结合 pprof + 实际流量回放，而不是只信 go test -bench 的那一行数字。
