resettimer必须在初始化完成后、循环开始前调用，否则会清零并重启计时器，导致内存分配等关键指标未被测量；常见错误是将其置于函数开头或for循环内。
ResetTimer必须放在初始化完成之后、循环开始之前
它不是“暂停计时”，而是把已累计的耗时和内存分配全部清零，并立即重启——所以位置错了，整个测试就废了。常见错误是把它写在函数开头，或者塞进for循环里。
典型错误写法：b.ResetTimer()放在make([]int, 1e6)之前，结果连内存分配都测不进去；或者写在for i := 0; i 里面，导致每次迭代都重置，最终<code>ns/op趋近于 0 或直接 panic（Go 1.21+）。
- ✅ 正确顺序：构造数据 → 预热缓存（如首次调用
json.Marshal）→ 调用b.ResetTimer()→ 进入for循环执行被测逻辑 - ❌ 错误顺序：调用
b.ResetTimer()→ 构造大 slice → 循环处理 → 实际计时包含构造开销 - ⚠️ 注意：如果初始化本身依赖
b.N（比如要按迭代次数预热 pool），得先用小规模跑几轮，再调b.ResetTimer()
复杂初始化常包含哪些必须排除的操作
这些操作真实存在、不可或缺，但不该计入核心逻辑耗时——它们会严重污染ns/op和allocs/op数值，尤其当初始化耗时远大于被测逻辑时（比如加载 5MB 配置花了 8ms，而实际处理只要 200ns）。
- 构建大型结构：如
make([]byte, 1e7)、填充含 10 万 key 的map[string]int - 打开外部资源：如
os.Open文件、sql.Open连接池初始化、HTTP client 设置 transport - 冷启动预热：首次调用
regexp.Compile、template.Parse、或encoding/json反射缓存填充 - sync.Pool 或临时目录创建：这类资源需复用，但创建过程不属于被测行为
嵌套 Benchmark 中 ResetTimer 必须每个子函数单独调
Go 1.21+ 起，b.ResetTimer()不再继承父级状态。你在外层调了，对b.Run("xxx", func(b *testing.B) { ... })内部完全无效——这会导致所有子 benchmark 都把 setup 时间算进去，数值不可比。
- ✅ 每个
b.Run子函数第一行就是b.ResetTimer() - ❌ 外层调一次，指望内层自动生效（Go 1.20 及以前可行，1.21+ 已失效）
- ? 示例：
b.Run("std", func(b *testing.B) { b.ResetTimer(); json.Unmarshal(data, &v) })，data必须在外层构造好
什么时候该换用 StopTimer/StartTimer 而不是 ResetTimer
b.ResetTimer()只解决“一次性排除初始化”的问题；如果每次迭代都要做准备+执行+清理，且只有中间段要计时，就得用b.StopTimer()和b.StartTimer()配对。
- 适用场景：每次循环都新建
map、重置bytes.Buffer、生成随机输入、关闭响应体 - ⚠️ 必须成对出现：漏掉
b.StartTimer()，整段循环不计时，结果变成0.00 ns/op——看似飞快，实为无效测试 - ⛔ 不能用于
b.RunParallel：并发基准中只能靠b.ResetTimer()控制全局起点，Stop/Start 不支持
最易被忽略的是：ResetTimer 不影响b.N递增，也不跳过任何代码执行——它只是让秒表归零重跑。别指望它帮你省掉初始化步骤，那得靠你手动组织代码结构。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
