Golang单例模式有哪些实现方式_常见单例写法对比解析_技术教程

Go中最安全的单例写法是用sync.Once配合包级指针变量，确保线程安全、无竞态、仅初始化一次；错误在于将Once放在结构体中或滥用init()、DCL。

Go 里最安全的单例：sync.Once + 指针变量

直接用 sync.Once 配合指针变量初始化，是 Go 官方推荐、线程安全、无竞态、无重复初始化的写法。它不依赖包级变量锁或反射，启动快、语义清晰。

常见错误是把 sync.Once 放在结构体里，当成实例方法调用——这会导致每个实例都带一个 Once，完全失去单例意义。

必须把 once 和单例指针都声明为包级变量（var），且 once 不可导出（小写开头）
getInstance() 函数内只做一次初始化，返回指针；后续调用直接返回已初始化的指针
初始化函数里不能有 panic，否则 Once 会认为执行失败并永远卡住（不会重试）

var (
    instance *Config
    once     sync.Once
)

func GetConfig() *Config {
    once.Do(func() {
        instance = &Config{Port: 8080, Timeout: 30}
    })
    return instance
}

为什么不用 init() 做单例？

init() 确实能保证只执行一次，但它发生在包加载时，无法按需延迟初始化，也不支持传参或错误处理。一旦初始化失败（比如配置读取异常），整个包加载失败，程序直接 panic，不可恢复。

更隐蔽的问题是：如果多个包 import 了该单例包，但主程序没显式使用它，Go 可能因优化跳过其 init() —— 实际行为取决于构建时的依赖图和 -gcflags 设置，非常难调试。

init() 适合无副作用、无外部依赖的静态初始化（如注册器、常量映射表）
涉及 I/O、网络、配置解析等场景，一律避开 init()
单元测试中，init() 无法重置或 mock，会污染测试上下文

懒汉式+双重检查锁（DCL）在 Go 中不必要且易错

Java/C++ 里常用 DCL 防止每次加锁，但在 Go 中，sync.Once 已经做了极致优化：首次调用有原子操作开销，之后是纯内存读取，性能接近直接访问变量。自己手写 DCL 不仅冗余，还容易写出有竞态的代码。

典型错误写法：if instance == nil { mutex.Lock(); if instance == nil { instance = new(...) } mutex.Unlock() } —— Go 的内存模型不保证写入对其他 goroutine 的可见顺序，缺少 atomic 或 sync 同步，可能返回未完全构造的对象。

Go 编译器不保证结构体字段写入的发布顺序，没有 volatile 语义
即使加了 mutex，若未在临界区内完*部初始化（比如中间调用了可能 panic 的函数），仍可能留下半初始化状态
所有 DCL 手动实现都应被 sync.Once 替代，这是 Go 团队明确建议的

带错误返回的单例初始化怎么写？

标准 sync.Once 不支持返回 error，所以需要封装一层：用一个私有全局变量缓存初始化结果（*T）和 error，并用 sync.Once 保证只执行一次初始化逻辑。

关键点在于，不能把 error 当作“初始化失败后可重试”的信号——Once 只认执行完成，不管成功失败。所以要靠额外标志位或非空判断来区分状态。

初始化函数内捕获所有 error，存到包级 err 变量，同时设置实例指针
对外接口统一返回 (*T, error)，调用方必须检查 error，不能假设非空指针就代表可用
避免在初始化函数里做耗时重试（如反复连 DB），应由上层控制重试策略

var (
    client *http.Client
    initErr error
    once   sync.Once
)

func GetHTTPClient() (*http.Client, error) {
    once.Do(func() {
        c, err := newHTTPClient()
        client, initErr = c, err
    })
    return client, initErr
}