应于初始化、预热等非核心逻辑前调用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前的计时残留影响后续结果。
- 推荐模板：
StopTimer
-
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系列方法
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
