延迟加载必须嵌入真实请求路径进行端到端压测，因其真实风险在于多goroutine并发调用初始化时的竞争、panic崩溃、重试堆积、超时传播等问题，而go test -bench仅测单次纳秒级耗时，无法覆盖HTTP生命周期、DNS、TLS、连接池等真实延迟源。
延迟加载本身不是接口，不能直接压测；必须把它嵌入真实请求路径里，用端到端压测暴露初始化竞争、超时、重试失败等问题。
为什么不能单独对 lazy.Group 或 sync.Once 做 go test -bench
go test -bench 测的是单次初始化函数的纳秒级耗时，不触发并发争抢——而延迟加载的真实风险恰恰在“多个 goroutine 同时调用 getBackend()”那一瞬间。它不会暴露：sync.Once.Do 里 panic 导致后续所有请求失败；也不会体现 lazy.Group 初始化失败后反复重试拖慢首字节时间。更关键的是，bench 不走 HTTP 生命周期，根本测不到 DNS 解析、TLS 握手、连接池等待这些真实延迟源。
怎么把延迟加载放进压测路径里
核心是让每个压测请求都触发一次目标服务的获取逻辑，例如代理场景下的 p.getBackend(r.Host)。必须确保：
- 权限校验和 token 解析放在
getBackend()调用之前，否则 body 可能被提前读空 - 转发请求前复制 header：
req.Header.Clone()，避免并发修改污染 - 禁用 keep-alive：
Transport.DisableKeepAlives = true，否则会掩盖 accept 队列打满问题 - 每个请求使用独立
context.WithTimeout，防止某个上游初始化卡死拖垮整批请求
压测时重点监控哪些指标
延迟加载的脆弱点不在平均延迟，而在长尾和失败传播：
立即学习“go语言免费学习笔记（深入）”；
- P99 初始化耗时：排序所有
getBackend()耗时，取第 99% 位，看是否突增（说明锁争抢或重试堆积） - 初始化失败率：
len(filterByErr(results)) / total，不是看 HTTP 状态码，而是捕获lazy.Group.Get返回的error - goroutine 数量趋势：用
pprof每 10 秒抓一次/debug/pprof/goroutine?debug=2，确认没因初始化阻塞导致 goroutine 泄漏 - 首次请求延迟 spike：对比第 1 个请求和第 100 个请求的
time.Since(start)，若差值 >200ms，大概率是 lazy 初始化阻塞了响应流
容易被忽略的初始化陷阱
很多人只测“初始化成功”，却忘了初始化过程本身可能破坏稳定性：
-
sync.Once里 panic 会导致整个进程 crash，而lazy.Group失败只是返回 error，行为完全不同 - 初始化函数里调用了
http.Get却没设Timeout，高并发下大量 goroutine hang 在 DNS 或 connect 阶段 - 懒加载的目标服务（如 DB 连接池）健康检查只做一次，后续连接断开没自动重连，压测中段开始批量报错
- 没控制初始化并发度，1000 个 goroutine 同时执行
getBackend()，触发文件描述符耗尽或net.Dial超时
真正要验证的不是“它能不能初始化”，而是“它在并发冲击下会不会成为系统瓶颈或故障放大器”。这只能靠带真实流量、带错误注入、带 pprof 观测的端到端压测来回答。
