应于初始化、预热等非核心逻辑前调用b.StopTimer()暂停计时，完成后再调b.ResetTimer()重置并重启计时器，确保仅测量目标代码执行耗时。
Go性能测试中什么时候该调用testing.B.StopTimer
不是所有初始化代码都该计入基准测试耗时——比如建立数据库连接、预热缓存、生成测试数据这些操作，只做一次，但会严重拖慢B.N循环的平均值。Go的testing.B提供StopTimer和StartTimer，专门用来排除这类“冷启动开销”。
典型场景：你要测一个HTTP handler的吞吐量，但每次b.Run前都要构造request、初始化router。这些不该算进handler执行时间里。
- 必须在
b.ResetTimer()之前调用StopTimer（否则重置无效） -
StopTimer后调用b.ReportAllocs()仍有效，内存统计不受影响 - 不能在
b.N循环内部调用StopTimer——它只控制整个基准函数的计时开关，不是为单次迭代设的
testing.B.StopTimer和ResetTimer的配合顺序
顺序错了会导致计时器状态异常，比如ResetTimer被忽略，或者后续StartTimer没效果。正确流程是：先StopTimer → 做初始化 → ResetTimer → StartTimer（可选，因为ResetTimer默认就重启）→ 进入b.N循环。
常见错误写法：b.ResetTimer()放在StopTimer之前，结果初始化耗时仍被计入；或者漏掉ResetTimer，导致前面StopTimer前的计时残留影响后续结果。
立即学习“go语言免费学习笔记（深入）”；
- 推荐模板：
func BenchmarkFoo(b *testing.B) {
// 1. 停止计时
b.StopTimer()
<pre class="brush:php;toolbar:false;">// 2. 初始化（DB连接、预分配切片、构建测试对象等）
data := make([]int, 1000)
for i := range data {
data[i] = i * 2
}
// 3. 重置并重启计时器（ResetTimer隐式StartTimer）
b.ResetTimer()
// 4. 实际被测逻辑
for i := 0; i < b.N; i++ {
_ = process(data)
}}
为什么StopTimer不能替代benchmem或ReportAllocs
StopTimer只影响CPU时间统计，完全不干预内存分配行为。如果你关心GC压力或堆分配次数，必须显式调用b.ReportAllocs()，且这个调用位置无关计时状态——它在StopTimer前后都生效。
另一个易混淆点：-benchmem命令行参数只是开启内存统计输出，真正触发统计的是ReportAllocs。没调用它，即使加了-benchmem也只会显示0 B/op和0 allocs/op。
-
StopTimer：控制ns/op数值是否包含某段代码 -
b.ReportAllocs()：启用对b.N循环内所有操作的内存分配采样 - 二者独立，常一起用，但作用域不同
容易被忽略的并发安全细节
testing.B方法不是并发安全的——如果在b.N循环里并发调用StopTimer或StartTimer（比如用go func()启动多个goroutine并在其中调用），会导致panic或计时器状态错乱。Go官方文档明确说明：所有B方法必须在主goroutine中调用。
真实踩坑案例：有人想模拟高并发请求，在循环里起10个goroutine跑handler，每个都调b.StopTimer，结果测试直接崩溃，报fatal error: concurrent map writes（底层timer维护用了map）。
- 正确做法：把并发逻辑封装进被测函数内部，计时器开关只在主goroutine里操作
- 如果真要测并发吞吐，用
b.RunParallel，它内部已处理好计时同步 - 绝对不要在goroutine里调
b.*Timer系列方法
