sync.Once 仅保证函数执行一次，但不处理失败重试、依赖隔离和健康检查；应依场景选 lazy.Group（支持重试）或预热+懒加载组合。
用 sync.Once 是最直接、最安全的解法，但必须配对使用正确的初始化模式，否则照样会重复或卡死。
为什么 sync.Once 本身不能防住所有重复初始化
sync.Once 确保函数只执行一次，但它不处理失败重试、不隔离依赖、也不感知上下文状态。常见误用包括：
- 在
init()函数里调用once.Do()—— init 阶段本就是单次同步执行，加Once纯属冗余，还误导后续维护者 - 把耗时操作（如
http.Get、db.Ping()）直接塞进Do的闭包里，导致首请求阻塞，且失败后永远无法重试 - 仅靠 “是否执行过” 判断资源可用性，忽略健康检查 —— 比如数据库连接池初始化成功了，但后续连接全断开，再调用仍返回已失效实例
带错误重试的懒加载：用 lazy.Group 替代裸 sync.Once
当后端服务可能启动失败、网络暂时不可达，或需要后台自动恢复时，sync.Once 就不够用了。此时应改用 golang.org/x/sync/lazy 中的 lazy.Group：
-
lazy.Group的Load()方法返回(T, error)，失败不锁死，下次调用可重试 - 支持设置超时、重试间隔、最大重试次数（需自行封装逻辑）
- 适合代理场景中“目标服务未就绪时先返回降级响应，后台持续尝试初始化”
示例片段：
立即学习“go语言免费学习笔记（深入）”；
var backendGroup lazy.Group
func getBackend(host string) (*Backend, error) {
return backendGroup.Load(func() (*Backend, error) {
addr := resolveHost(host)
conn, err := net.Dial("tcp", addr)
if err != nil {
return nil, fmt.Errorf("dial failed: %w", err)
}
return &Backend{Conn: conn}, nil
})
}
并发转发场景下，别在每次请求里 new struct
HTTP 代理中常按 Host 或路径路由到不同后端，如果每次请求都调用 &Backend{...} 构造新实例，不仅浪费内存，还绕过了懒加载的意义：
- 用
sync.RWMutex+ 懒初始化 map 缓存已创建的后端实例，key 为 host - 读多写少场景下，
RWMutex比单纯sync.Mutex更高效 - 注意：不要在
mapvalue 里存未校验健康状态的连接，转发前务必做轻量探活（如conn.SetWriteDeadline后写一个空字节）
权限检查和延迟加载的顺序不能错
权限控制必须在读取 req.Body 前完成，否则 body 流被消耗，后续转发失败；而延迟加载目标服务又得在权限通过之后——这个时序一旦颠倒，整个代理链就崩了：
- 正确顺序：解析请求 → 权限检查（从
r.Header.Get("Authorization")提取 token）→ 目标发现（懒加载 backend）→ 转发 - 错误做法：在
RoundTrip阶段才验签，或在转发后再检查权限 - 特别注意：
req.Body是io.ReadCloser，只能读一次；若权限检查需要解析 JSON body，得先用io.ReadAll读出并重新构造req.Body
真正容易被忽略的是：懒加载不是越晚越好。把所有初始化都压到首请求里，会导致 P95 延迟飙升；该预热的（比如配置、日志句柄）还是得在启动阶段做，该延迟的（比如冷门后端连接、debug 接口依赖）才用 Once 或 lazy.Group 控制时机。
