sync.Lazy是Go 1.21+引入的值语义类型，封装sync.Once与原子状态，确保并发安全、一次性初始化及错误传播；相比手写sync.Once+指针，它更简洁、防nil panic、自动缓存结果。
用 sync.Lazy（Go 1.21+）最直接；老版本用 sync.Once + 指针字段手动控制；别依赖闭包捕获变量来“假装懒加载”，那只是延迟执行，不是线程安全的延迟初始化。
sync.Lazy 是什么，为什么比手写 Once 更稳
sync.Lazy 是 Go 1.21 引入的值语义类型，内部封装了 sync.Once 和原子状态，自动处理并发安全、错误传播和一次性初始化。它不是接口或指针，而是结构体字段，赋值即声明“这个值要懒加载”。
- 初始化函数只运行一次，即使多个 goroutine 同时首次访问
l.Load() - 如果初始化函数返回 error，
l.Load()下次调用仍会重试（除非你显式缓存错误） - 不能像指针那样被意外置为
nil，也不会因未初始化字段导致 panic - 示例：
var expensive = sync.Lazy{Init: func() any { time.Sleep(100 * time.Millisecond) // 模拟耗时 return strings.Repeat("x", 1e6) }} // 首次调用才执行 Init，后续直接返回结果 data := expensive.Load().(string)
老版本（Go
常见错误是把值直接存在 struct 字段里，或者用闭包捕获局部变量——这些都不防并发，也不保证只初始化一次。
- 字段必须是指针类型（如
*string），初始为nil，靠sync.Once控制首次赋值 - 别在
Init函数里做阻塞操作（比如同步读大文件），否则所有首次调用都会卡住 - 如果初始化可能失败，建议额外加一个
err error字段缓存错误，避免反复重试 - 示例：
type LazyConfig struct { data *string once sync.Once err error } func (l *LazyConfig) Get() (string, error) { l.once.Do(l.init) if l.err != nil { return "", l.err } return *l.data, nil } func (l *LazyConfig) init() { result, err := fetchFromRemote() if err != nil { l.err = err return } l.data = &result }
为什么不能用闭包模拟延迟加载
像 func() string { ... } 这种闭包确实能推迟计算，但它不解决两个关键问题：并发安全、结果复用。
- 每次调用闭包都重新执行逻辑，不是“首次加载后缓存结果”
- 没有锁或 once 机制，多个 goroutine 并发调用会重复加载资源（比如重复打开文件、重复请求远程配置）
- 无法区分“还没加载”和“加载失败”，错误处理困难
- 这种写法适合惰性求值（lazy evaluation）场景，比如生成器或条件分支里的计算，但不是延迟初始化（lazy initialization）
延迟加载字段该放在哪，什么时候初始化
放在 struct 里还是全局变量，取决于生命周期和并发需求。
- 如果是服务级单例配置（如数据库连接池、远程 schema），放全局
var最自然，sync.Lazy或sync.Once都适用 - 如果是每个请求/实例独享的昂贵对象（如 per-request TLS config），不要放 struct 字段里靠 getter 加载——容易被忘记初始化，或在并发下出错；改用工厂函数 + context.CancelFunc 管理生命周期
- 永远不要在
init()函数里做延迟加载：它本就是包初始化阶段运行的，失去“延迟”意义 - 如果初始化依赖其他已懒加载字段，注意循环依赖风险；
sync.Lazy不自动解依赖，得靠代码顺序或手动拆解
真正容易被忽略的是错误状态的持久化——很多实现只管“成功后缓存”，却让失败重试无限进行，拖垮请求响应时间。要么缓存错误并加退避，要么用 lazy.Group（来自 golang.org/x/sync）接管重试策略。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
