该用 sync.Once 而不是自己加锁懒加载，核心是确保初始化只执行一次且线程安全；它内置原子判断与执行控制，避免漏掉双重检查或忘记解锁导致的竞态。
什么时候该用 sync.Once 而不是自己加锁
懒加载最核心的诉求是：确保初始化代码只执行一次，且线程安全。自己用 mutex 加锁容易漏掉双重检查（double-check）或忘记 unlock，反而引入竞态。Go 标准库的 sync.Once 就是专为这个场景设计的——它内部已做原子判断和执行控制，调用 Do 方法时，无论多少 goroutine 并发调用，传入的函数只会被执行一次。
常见错误是：在 init 函数里直接初始化全局变量，或在包级变量声明时就调用构造函数，这会丢失“懒”的语义；更糟的是，在方法里每次访问都去 check + lock + init，性能差且逻辑冗余。
-
sync.Once是零值安全的，声明即可用，无需显式初始化 - 一旦
Do中的函数返回（无论是否 panic），后续调用不会再执行它 - 如果初始化函数可能失败，需自行捕获 error 并存到变量中，
sync.Once不提供失败重试机制
sync.Once 配合指针字段实现延迟构建
典型场景是结构体中某个 heavy 字段（比如数据库连接池、配置解析器、缓存实例）不希望在结构体创建时就初始化，而是在首次被访问时才构建。这时应把该字段声明为指针类型，并搭配 sync.Once 字段一起使用。
type Service struct {
db *sql.DB
dbOnce sync.Once
}
func (s *Service) GetDB() *sql.DB {
s.dbOnce.Do(func() {
// 这里放实际初始化逻辑，比如 sql.Open
s.db = mustOpenDB()
})
return s.db
}
注意：不能把 sync.Once 放在方法内局部变量里，否则每次调用都新建一个 Once，失去“只执行一次”的意义；也不能把 db 声明为值类型（如 sql.DB），因为 Go 中 sql.DB 本身是引用类型，但按值传递会导致拷贝其内部 mutex 等状态，引发 panic。
立即学习“go语言免费学习笔记（深入）”；
初始化失败后如何让后续调用感知错误
sync.Once.Do 不暴露执行结果，所以初始化函数里发生的 error 默认会被吞掉。若业务需要区分“未初始化”“初始化失败”“初始化成功”，就得额外维护状态变量。
- 用一个
err字段记录初始化错误，配合sync.Once使用 - 在
GetDB返回前检查该err，非 nil 则直接返回或 panic - 避免在
Do函数里直接 panic——这会让调用方无法 recover，且sync.Once仍视为“已完成”，后续调用拿不到新机会
示例关键片段：
type Service struct {
db *sql.DB
err error
once sync.Once
}
func (s *Service) GetDB() (*sql.DB, error) {
s.once.Do(func() {
db, err := sql.Open("mysql", dsn)
if err != nil {
s.err = err
return
}
s.db = db
})
return s.db, s.err
}
为什么不用 lazy 第三方包或 atomic.Value
有些项目会引入类似 github.com/panjf2000/lazy 的包，或者尝试用 atomic.Value 存储初始化后的对象——前者增加了依赖且功能重叠；后者虽可安全读写，但无法解决“仅初始化一次”的协调问题，仍需外部同步机制（比如再套一层 sync.Once），徒增复杂度。
真正需要替代 sync.Once 的情况极少，比如：初始化逻辑需支持取消（context.Context）、超时控制、或依赖注入容器管理生命周期。这种时候应考虑更高层的框架抽象（如 uber-go/fx、go.uber.org/dig），而不是在懒加载层面做定制。
最易被忽略的一点：sync.Once 不是银弹。如果初始化成本极低（比如只是 new 一个空 struct），或对象生命周期本就由上层统一管理（如 HTTP handler 中每次请求新建 service 实例），强行加懒加载反而增加心智负担和间接调用开销。
