Go单例必须用sync.Once而非简单加锁，因其通过原子状态+互斥锁确保初始化函数仅执行一次且完全完成；若Do内panic，状态仍标记为已执行，后续调用直接返回，可能导致nil指针解引用。
为什么 Go 单例必须用 sync.Once 而不是简单加锁
因为仅靠 mutex.Lock() 无法避免「双重检查失败」导致的多次初始化。常见错误是：先判断指针是否为 nil，再加锁、再判断、再创建——但两个 goroutine 可能在第一次判断后同时进入临界区，造成重复执行 new() 或初始化逻辑。
sync.Once 的核心价值不是“加锁”，而是“确保函数只执行一次且完全完成后再返回”，它内部用原子状态 + 互斥锁组合，天然规避了竞态窗口。
sync.Once 初始化函数里 panic 会怎样
如果传给 once.Do() 的函数 panic，sync.Once 会把状态标记为“已执行”，后续调用 Do() 不再执行该函数，也不会重试，直接返回。这意味着单例对象可能未成功构造，后续使用该对象大概率触发 nil pointer dereference 或其他异常。
- 务必在
Do()包裹的函数内做完整错误处理，不要让 panic 泄露出去 - 推荐模式：
var once sync.Once var instance *Config var err error func GetConfig() (*Config, error) { once.Do(func() { instance, err = loadConfig() // 返回 (*Config, error) }) return instance, err }
不用 sync.Once 的替代方案有哪些？为什么不推荐
有人用 atomic.Value + CompareAndSwapPointer 手动实现，或用 init() 函数——但都有硬伤：
立即学习“go语言免费学习笔记（深入）”；
-
init()只能在包加载时运行，无法延迟初始化（比如依赖配置文件、网络连接等） - 手动原子操作极易出错：漏掉内存屏障、忘记处理 ABA 问题、或误判指针比较结果
- 全局 mutex + double-check 模式在高并发下性能差，且仍需仔细设计判断顺序，稍有不慎就失效
sync.Once 是标准库经过长期验证的最小可行抽象，代码少、语义明确、无额外依赖。
多个单例共用一个 sync.Once 实例会怎样
不能复用。每个单例必须配独立的 sync.Once 字段或变量。因为 sync.Once 的状态是绑定到「某次 Do() 调用」的，不是绑定到类型或值的。
下面这段是错的：
var once sync.Once
var a *ServiceA
var b *ServiceB
func GetA() *ServiceA {
once.Do(func() { a = new(ServiceA) })
return a
}
func GetB() *ServiceB {
once.Do(func() { b = new(ServiceB) }) // 这里永远不会执行！
return b
}
第二个 Do() 直接跳过——once 已被标记为 done。线程安全的前提是「一单一例一 Once」。
