resettimer 必须在基准测试中初始化和非被测逻辑之后、实际性能测量循环之前调用，以排除初始化等无关开销对计时结果的影响。
ResetTimer 什么时候必须调用
在 testing.B 的基准测试中，ResetTimer 不是“可选优化”，而是**控制计时范围的核心开关**。如果你的 Benchmark 函数里做了初始化（比如构建大 slice、打开文件、预热 map）、或包含非被测逻辑（如日志打印、结果校验），这些耗时会被默认计入总时间——导致结果严重失真。
典型错误写法：
func BenchmarkBad(b *testing.B) {
data := make([]int, 1000000) // 初始化开销被计时了
for i := range data {
data[i] = i
}
for i := 0; i
<p>上面的 <code>make</code> 和初始化循环实际占用了大量时间，但你真正想测的是“遍历求和”这个操作。</p>
<h3>ResetTimer 正确调用位置</h3>
<p><code>ResetTimer</code> 必须在所有**一次性前置工作完成后、进入循环前立即调用**。它会把当前已累计的纳秒数清零，后续 <code>b.N</code> 次迭代才开始真实计时。</p>
- 不能放在循环内部（会导致每次迭代都重置，最终时间趋近于 0）
- 不能放在循环之后（毫无意义）
- 如果有多阶段预热（比如先 warmup cache 再正式测），可在每阶段后按需调用，但通常只需一次
修正后的写法：
func BenchmarkGood(b *testing.B) {
data := make([]int, 1000000)
for i := range data {
data[i] = i
}
b.ResetTimer() // ✅ 关键：重置计时器，排除初始化干扰
for i := 0; i
<h3>ResetTimer 和 StopTimer / StartTimer 的区别</h3>
<p><code>ResetTimer</code> 是“清零并继续计时”，而 <code>StopTimer</code>/<code>StartTimer</code> 是“暂停/恢复计时”。三者适用场景不同：</p>
-
ResetTimer：适合单次初始化后批量测量（最常用） -
StopTimer+StartTimer：适合需要穿插非测量逻辑的复杂流程，比如每次迭代中都要做一次 setup/cleanup
例如，每次迭代都要新建一个 sync.Pool 并清理，又不想把 pool 创建/销毁算进性能数据：
func BenchmarkWithSetup(b *testing.B) {
for i := 0; i
<h3>ResetTimer 调用后还能改 b.N 吗</h3>
<p>不能。一旦调用 <code>b.ResetTimer()</code>，<code>b.N</code> 就已由 go test 确定并锁定。后续修改 <code>b.N</code> 不会影响本次运行的迭代次数，也不会触发重新采样——它只是个只读字段。</p>
<p>更关键的是：<code>ResetTimer</code> 不会重置 <code>b.N</code>，也不会影响内存分配统计（<code>b.ReportAllocs()</code> 仍统计整个函数生命周期）。如果初始化阶段有大量临时分配，它们仍会计入 <code>allocs/op</code>，这时得靠 <code>b.StopTimer</code> 配合手动控制。</p>
<p>容易忽略的一点：Go 1.21+ 对 <code>ResetTimer</code> 做了优化，但如果在 <code>init()</code> 或包级变量初始化里做了重型操作，那些开销依然无法被 <code>ResetTimer</code> 排除——得挪到 benchmark 函数内，并在 <code>ResetTimer</code> 前完成。</p>golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
