sync.once 在基准测试中无法重置，因其 done 字段设为 1 后不可逆，且 testing.b 无 cleanup 机制，子基准不共享父 defer 栈，导致状态复用、结果失真。
基准测试中延迟加载的状态重置不能靠 defer 或全局变量复位，因为 testing.B 没有 Cleanup 机制，且子基准（b.Run）不共享父基准的 defer 栈——这意味着你初始化一次 sync.Once 或 lazy.Group，后续所有迭代都会复用已初始化的状态，导致结果失真。
为什么 sync.Once 在基准测试中无法重置
sync.Once 是一次性开关，内部字段 done uint32 被设为 1 后永远不可逆。你在 BenchmarkXxx 函数里调用 once.Do(...)，哪怕在 for i := 0; i 循环内，也只触发一次。后续迭代读到的仍是上一轮留下的已初始化实例（比如一个已连接的数据库连接、一个已填充的缓存 map），根本不是“干净状态”下的性能表现。
- 常见错误现象：
go test -bench=.显示 ns/op 极低，但实际逻辑包含大量预热开销；不同 benchmark 之间数值不可比 - 典型场景：测试带懒加载后端的 HTTP 代理时，第一次请求初始化了
backend，之后所有迭代都直接复用，压根没测“首次发现+初始化”的真实耗时 - 根本原因：延迟加载本意是“首次访问才创建”，但基准测试需要的是“每次迭代都从零开始”，二者目标冲突
如何手动重置 lazy.Group 实例
lazy.Group（来自 golang.org/x/sync）本身不提供重置方法，但它的状态全在内部字段里。你可以通过反射或更稳妥的方式——封装一层可重置的 wrapper，并在每次迭代前显式调用 reset()。
- 不要直接暴露
lazy.Group字段，而是把它包进结构体，例如：type ResettableLazy struct { once lazy.Group; value interface{}; err error } - 实现
Reset()方法：清空value和err，并用unsafe或重新分配方式绕过once的不可逆性（实践中更推荐重建实例） - 更简单可靠的做法：每次迭代前
new(ResettableLazy)，而非复用旧实例——毕竟基准测试本就不该共享状态 - 注意：若
lazy.Group初始化函数里有副作用（如启动 goroutine、监听端口），重置后必须确保这些资源被显式关闭，否则会泄漏
b.StopTimer() + 手动重建才是正解
延迟加载的“重置”，本质是销毁旧实例 + 清理资源 + 重建新实例。这三步必须放在 b.StopTimer() 保护下，否则清理和重建开销会被计入性能指标。
- 正确顺序：
b.StopTimer()→ 关闭旧连接 /resetMap()/new(ExpensiveResource)→b.StartTimer()→ 调用被测函数 - 示例：测试一个懒加载 DB 的查询函数
func BenchmarkQueryWithLazyDB(b *testing.B) { for i := 0; i - 切忌把
b.StopTimer()放在循环外——那样只停一次，后续迭代的重建操作全被计时；也别漏掉b.StartTimer()，否则整个循环不计时
延迟加载 + 重试组合时的陷阱
如果懒加载逻辑本身含重试（比如用 retry-go 初始化后端），那重置不仅要销毁实例，还要中断可能仍在运行的重试 goroutine，否则会堆积大量后台任务。
- 常见错误：
lazy.Group初始化函数里启了一个带time.AfterFunc的重试循环，Reset()只清了value，但定时器还在跑 - 安全做法：初始化函数返回的实例必须带
Stop()或Cancel()方法，并在重置前显式调用 - 更彻底的方案：不用
lazy.Group，改用带 context 的初始化函数，每次传入新context.WithCancel，重置时 cancel 即可 - 容易被忽略的一点：即使你重置了懒加载实例，如果底层资源（如 TCP 连接池、文件句柄）未释放，OS 层面仍会累积压力——基准测试要测的从来不只是 Go runtime，还有系统资源消耗
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
