Go 中用 sync.Once 做单例比包级变量更可靠，因其保证初始化函数有且仅执行一次并自带同步语义，避免并发重复初始化导致的资源泄漏或竞态；而包级变量无同步机制，并发下可能多次执行构造逻辑。
为什么 Go 里用 sync.Once 做单例比包级变量更可靠
包级变量（比如 var config *Config）看似简单，但并发初始化时可能多次执行构造逻辑，尤其在配置加载含 I/O 或解析开销时，会引发重复连接、资源泄漏或竞态。而 sync.Once 保证 Do 内函数**有且仅执行一次**，且自带同步语义，无需手动加锁。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 把配置结构体初始化封装进一个私有函数，例如
loadConfig()，只在sync.Once.Do中调用它 - 不要在
init()函数里做重操作——它无法捕获错误，也无法延迟到首次使用时才触发 - 避免把
sync.Once实例暴露为导出字段；它应是内部状态，配合惰性初始化使用
如何安全暴露全局配置实例而不破坏封装
直接导出 var Config *Config 看似方便，但调用方可能绕过初始化逻辑、直接赋值或置为 nil，导致 panic。正确做法是只导出访问函数，如 GetConfig()，内部控制实例生命周期。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 定义
func GetConfig() *Config，内部用once.Do(initConfig)+ 返回已初始化的指针 - 如果配置需要热重载，
GetConfig()不应返回指针别名，而应返回拷贝或带版本号的只读视图，防止外部修改影响全局状态 - 不要在
GetConfig()里做耗时操作（如重新读文件），那会拖慢每次调用；初始化应一次性完成
数据库连接池这类资源，单例初始化失败怎么处理
配置单例常依赖下游服务（如 Redis、PostgreSQL），初始化失败时若静默忽略，后续调用 GetConfig().DB.Query(...) 会 panic。必须让失败可感知、可恢复。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 在
initConfig()中显式检查关键字段（如DSN）、尝试建立测试连接，并返回 error - 用双检查模式：
sync.Once只保证执行一次，但需额外加锁或原子变量记录是否“初始化成功”，失败后再次调用GetConfig()才能报错而非返回 nil - 避免在
initConfig()中 panic——它会让整个包不可用；改用日志 + 返回 error，并在GetConfig()中判断是否初始化失败并 panic 或返回 sentinel error
为什么 sync.Once 不能解决所有并发问题，还得看资源本身是否线程安全
sync.Once 只保障初始化过程不重复，不代表你拿到的配置对象或连接池天然线程安全。比如自己写的 Config 结构体若含未加锁的 map 字段，多个 goroutine 并发读写仍会 panic；又如误把 *sql.DB 当作单例管理，其实它本身已是线程安全连接池，无需再套一层单例逻辑。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 确认底层资源是否已线程安全：
*sql.DB、*redis.Client、http.Client都是，只需确保它们被正确初始化并复用 - 自定义结构体若含可变状态（如缓存 map、计数器），必须用
sync.RWMutex或sync.Map显式保护 - 不要为了“单例”而单例——如果某资源本就该按请求隔离（如用户 session 上下文），强行全局单例反而引入隐式耦合和状态污染
真正难的不是写对 sync.Once，而是分清哪些状态该共享、哪些该隔离，以及初始化失败后调用方有没有合理 fallback 路径。很多人卡在“配置加载了但 DB 连不上”，其实是没把错误传播机制和资源可用性检查做进单例的契约里。
