BenchmarkFuncName 不会触发延迟加载逻辑，因为其默认从函数入口计时且 b.N 循环反复调用，除首次外均走快路径，导致 ns/op 严重低估初始化成本；正确做法是将首次加载单独剥离并在 b.ResetTimer() 前完成，或拆分为 BenchmarkLazyLoadOnce 和 BenchmarkLazyValueAccess 两个独立测试。
go test -bench=. 能跑出延迟加载的性能数据，但默认方式测出来的几乎全是假值——初始化开销、编译器优化、缓存干扰全没被控制，结果根本不可比。
为什么 BenchmarkFuncName 不会触发延迟加载逻辑？
延迟加载（比如 sync.Once、lazy.Load、或自定义的 once.Do 包装）本质是「首次调用才执行」。而基准测试默认从函数入口就开始计时，b.N 循环里反复调用，除第一次外全是快路径，导致 ns/op 严重低估初始化成本。
- 错误写法：
once.Do(initFunc); result = compute()放在循环内 → 首次之后全走缓存，测不到真实 init 开销 - 正确思路：把「首次调用」单独拎出来，在
b.ResetTimer()前完成；主循环只测「已加载后」的访问延迟 - 若目标就是测「首次加载耗时」，则整个 Benchmark 函数体只允许调用一次
once.Do，且不能放在循环里 —— 否则b.N > 1时框架会报错或静默跳过
如何分离「加载延迟」和「访问延迟」？
一个延迟加载模块通常包含两个可测维度：加载那一刻的开销（含锁、内存分配、I/O），以及后续无锁读取的开销。必须拆成两个独立 Benchmark 函数：
-
BenchmarkLazyLoadOnce：只调用一次once.Do(init)，不进循环；用b.ReportAllocs()+-benchmem看初始化是否触发堆分配 -
BenchmarkLazyValueAccess：先在b.ResetTimer()前完成加载，再在循环中反复读取已加载的值（如value.Load()或直接取全局变量） - 两者必须分开跑，否则
ns/op是混合值，无法定位瓶颈在加载还是访问
sync.Once 基准测试容易踩的坑
sync.Once 自身有轻量级原子操作，但它的性能陷阱不在它自己，而在你传给 Do 的函数里。常见问题：
- 忘记把初始化函数的副作用「固定下来」：比如
initFunc每次都新建 map、解析 JSON，这些开销会被计入首次延迟，但你可能只想测 Once 控制流本身 → 应提前构造好依赖对象，只把「赋值」动作交给Do - 在循环内重复调用
once.Do并期望它返回不同结果 → 它只会执行一次，其余调用立即返回，b.N越大，平均值越接近 0 ns/op，毫无意义 - 没禁用编译器优化：如果
once.Do的回调没有产生可观测结果（比如只改局部变量），Go 可能直接删掉整段逻辑 → 必须把关键输出赋给包级变量，例如var _ = loadedValue
真实场景下要加哪些控制参数？
延迟加载常用于配置加载、连接池初始化、模板编译等重操作，这类测试对环境敏感度高：
立即学习“go语言免费学习笔记（深入）”；
- 加
-benchtime=3s：避免默认 1 秒太短，导致采样次数少、抖动大 - 加
-count=5：跑 5 轮取中位数，排除单次 GC 或系统调度干扰 - Linux 下跑前执行
sync && echo 3 | sudo tee /proc/sys/vm/drop_caches：清页缓存，防止文件类延迟加载（如读 config.yaml）测出的是缓存速度 - 若初始化含 HTTP 请求或 DB 查询，务必用
&http.Client{Transport: &http.Transport{MaxIdleConns: 0}}关闭复用，否则测的是连接池命中率
Benchmark 函数里永远测不准。 
