Go 不推荐手写双重检查锁单例，因 sync.Once 已是内存安全、零分配且经优化的成熟实现；手写易出错、难维护，且无法获得编译器特殊优化。
为什么 Go 里不推荐手写双重检查锁（DCL）单例
Go 的 sync.Once 已经是经过充分验证、内存模型安全、且零分配的 DCL 实现。手动用 sync.Mutex + sync/atomic 模拟 DCL 不仅冗余，还极易出错——比如忘记用 atomic.LoadPointer 读取指针、漏掉 atomic.StorePointer 写入、或在非 unsafe.Pointer 场景误用原子操作。
更关键的是：Go 编译器和运行时对 sync.Once 有特殊优化，而自己写的 DCL 很难达到同等性能和安全性。
用 sync.Once 实现线程安全单例的正确姿势
核心是把初始化逻辑封装进一个无参函数，并由 Once.Do() 保证只执行一次。所有并发 goroutine 都会阻塞等待首次初始化完成，之后直接读取已初始化的变量。
-
sync.Once内部已处理内存屏障，无需额外atomic或unsafe - 初始化函数不能带参数；如需传参，请提前闭包捕获或通过包级变量间接传递
- 如果初始化可能 panic，
Once.Do()会传播 panic，且后续调用仍会 panic —— 这是设计行为，不是 bug - 不要重复声明多个
sync.Once控制同一实例，否则失去“单例”语义
var (
instance *Config
once sync.Once
)
func GetConfig() *Config {
once.Do(func() {
instance = &Config{Port: 8080, Timeout: 30}
})
return instance
}
什么时候真需要“双重检查”？比如延迟加载带参数的实例
若单例构造依赖运行时参数（如配置文件路径），又不想把参数硬编码进 Do 函数，可结合 sync.Once 和惰性初始化字段（如 sync.OnceValue（Go 1.21+）或自定义 once-with-arg 封装）。
但注意：sync.OnceValue 是为「返回值」设计的，它本身不接受参数；常见做法是用闭包捕获参数，或用 map/cache 管理多参数实例（此时已不属于严格单例）。
- Go 1.21+ 推荐：
sync.OnceValue+ 闭包，避免全局变量污染 - 低于 Go 1.21：可用
sync.Once+ 包级变量 + 初始化函数工厂 - 切勿为“看起来更可控”而回退到手写
atomic.LoadUint32+Mutex的 DCL
// Go 1.21+
var getConfigOnce = sync.OnceValue(func(path string) (*Config, error) {
data, _ := os.ReadFile(path)
return parseConfig(data), nil
})
func GetConfigByPath(path string) (*Config, error) {
return getConfigOnce(path)
}
容易被忽略的坑：nil 检查与接口类型单例
当单例类型是接口（如 io.Writer）时，直接判断 instance == nil 可能失效——因为接口底层是 (type, data) 结构，即使 data 为 nil，只要 type 非空，接口就不等于 nil。
所以永远别在 sync.Once 外层加 if instance == nil 判断，否则可能绕过同步逻辑，导致竞态或重复初始化。
- 所有初始化必须严格收口在
Once.Do()内部 - 如果初始化函数里需要检查资源是否已存在（如文件、连接），那是业务逻辑，不是同步逻辑
- 测试时用
-race运行，确认没有数据竞争 —— 即使用了sync.Once，错误的使用方式仍会触发竞态
真正复杂的点不在锁策略，而在初始化逻辑本身的幂等性和副作用控制。比如打开文件、建立数据库连接、启动 goroutine……这些操作一旦失败或部分成功，sync.Once 不会重试，也不会回滚。
