sync.Once.Do 安全是因它用原子状态位+互斥锁确保初始化函数仅执行一次，且阻塞并发调用者直至完成；需声明为包级变量并在Do中显式赋值实例，否则无效。
sync.Once.Do 为什么是安全的单例入口
Go 标准库的 sync.Once 不是“实现单例的工具”，而是“保证某段初始化逻辑只执行一次”的原语。它本身不管理实例生命周期，也不封装对象，但正因如此，它比手写锁或原子操作更轻、更可靠——只要把构造逻辑塞进 Once.Do 的函数参数里，就能天然规避竞态和重复初始化。
常见错误现象：sync.Once 被声明为局部变量（比如在函数内 new 出来），导致每次调用都新建一个 Once 实例，完全失去“只执行一次”的意义；或者误以为 Once 能自动缓存返回值，结果在 Do 里没把实例赋给包级变量，外部始终拿不到对象。
- 必须把
sync.Once声明为包级变量（或结构体字段），确保复用 -
Do的参数函数里，要显式完成实例创建 + 赋值（例如instance = &MyStruct{...}） - 不要试图从
Do的函数里 return 实例——它签名是func()，无返回值
最简可用的单例写法（带懒加载）
真正上线项目里，你几乎不会看到裸用 sync.Once 的“教学版”单例。因为懒加载+线程安全+可测试这三点必须同时满足，而最简结构就是：包级指针变量 + 包级 sync.Once + 初始化函数。
使用场景：数据库连接池、配置加载器、全局 logger 实例等需要延迟构建且全局唯一的服务对象。
立即学习“go语言免费学习笔记（深入）”；
var (
instance *Config
once sync.Once
)
func GetConfig() *Config {
once.Do(func() {
instance = &Config{Path: "/etc/app.conf"}
// 这里可以加文件读取、解析、校验等耗时逻辑
})
return instance
}
注意：如果 Config 构造可能失败（比如文件不存在），sync.Once 无法重试或透出错误——它只管“执行一次”，不管成功与否。这时候得自己加错误缓存（比如额外的 err 变量），否则第二次调用 GetConfig 会直接返回 nil。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
为什么不用 init 函数做单例
init 确实能保证包加载时只执行一次，但它在启动阶段就强制初始化，无法支持按需加载（懒加载）。更重要的是，它破坏了可测试性：单元测试时没法 mock 或替换依赖，也无法控制初始化时机（比如某些配置还没准备好）。
性能影响：对简单结构体，init 和 sync.Once 差距不大；但若初始化涉及 I/O、网络或复杂计算，init 会拖慢整个程序启动，而 sync.Once 把开销推迟到首次使用那一刻。
-
init在 main 启动前运行，不可中断、不可重试、不可依赖其他包的 init 结果（顺序不确定） -
sync.Once在第一次调用时才触发，可控、可测、可组合 - 如果初始化逻辑里要调用其他包的函数，用
init容易遇到循环 import 或初始化顺序 bug
并发调用 GetConfig 时的实际表现
多个 goroutine 同时首次调用 GetConfig，sync.Once 会阻塞其余 goroutine，只放行一个去执行初始化函数，其余等待其完成后再统一返回已构建好的实例。这个过程对调用方完全透明，不需要额外同步措施。
容易踩的坑：sync.Once 内部用的是互斥锁 + 原子状态位，虽然高效，但它不是无代价的——高频调用（比如每毫秒上千次）仍会产生锁竞争。不过真实业务中，单例获取极少成为瓶颈；真有这种需求，说明设计可能出了问题（比如把本该复用的对象当单例反复取）。
兼容性：从 Go 1.0 就存在，无版本顾虑；但注意别在 Do 函数里调用会 panic 的代码——sync.Once 不 recover，panic 会直接向上传播，且该 Once 实例此后永远处于“已完成”状态（即使初始化失败）。
