Go 不推荐手写 DCL 单例，因易因内存重排序、缺少 volatile 等价物或 atomic 使用不当导致返回未完全构造对象；官方推荐用 sync.Once 实现线程安全、零开销的一次性初始化。
为什么 Go 里不推荐手写 DCL 单例
Go 的 sync.Once 已经是线程安全、零开销的单例初始化原语，它内部用的是更可靠的状态机而非传统 Java 风格的 DCL。手写 DCL 容易因内存重排序、缺少 volatile 等价物（Go 没有该关键字）、或未正确使用 sync/atomic 而导致返回未完全构造的对象——这种 bug 在高并发下极难复现。
用 sync.Once 实现安全单例的最小模式
这是 Go 官方推荐且生产环境验证过的做法，本质是“一次性初始化 + 原子状态检查”，比 DCL 更简洁、更不易出错。
常见错误现象：直接在包级变量赋值（如 var instance *Singleton = newSingleton()）会导致初始化时机不可控，且无法延迟到首次使用；或用普通 mutex 包裹初始化逻辑，但没处理好竞态下的重复初始化。
- 把实例声明为包级指针变量，初始值为
nil - 定义一个私有初始化函数
newSingleton()，返回完整构造的对象 - 用
sync.Once控制该函数只被执行一次，后续调用直接返回已建好的实例
<pre class="brush:php;toolbar:false;">var (
instance *Singleton
once sync.Once
)
func GetInstance() *Singleton {
once.Do(func() {
instance = newSingleton()
})
return instance
}
如果非要模拟 DCL，必须加 atomic.LoadPointer 和 <code>atomic.CompareAndSwapPointer
Go 不允许对非原子类型做无锁读写判断，所以不能像 Java 那样简单用 if (instance == null) 两次检查。必须用 unsafe.Pointer + atomic 操作来模拟，但这会引入复杂性和可读性下降，仅建议用于学习或极端性能压测场景。
关键点：
- 实例字段必须是
*unsafe.Pointer类型（指向*Singleton的指针），否则无法原子读写 - 第一次检查用
atomic.LoadPointer，避免编译器/CPU 重排序导致看到部分构造对象 - 第二次检查必须在加锁后再次调用
atomic.LoadPointer，不能直接读变量 - 写入必须用
atomic.CompareAndSwapPointer，失败则说明别人已写入，直接返回
性能影响：相比 sync.Once，DCL 手动实现多了至少两次原子操作和一次锁竞争，在多数场景下反而更慢，且失去 sync.Once 对 panic 的自动屏蔽能力（once.Do 中 panic 不会传播）。
真正容易被忽略的初始化陷阱
单例是否真正“单”取决于初始化逻辑本身是否幂等。比如 newSingleton() 里打开了文件、注册了信号 handler、启动了 goroutine 或修改了全局状态，这些行为即使只执行一次，也可能因上下文不同产生副作用。
更隐蔽的问题是：如果 Singleton 依赖其他单例（比如日志器、配置管理器），而它们的初始化顺序没通过 init() 或显式调用控制好，就可能触发死锁或空指针 panic。
所以比起纠结锁策略，优先确保初始化函数是纯构造、无副作用、无外部依赖，或者把依赖注入进来——这才是 Go 单例稳定的关键。
