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 设置，非常难调试。
立即学习“go语言免费学习笔记（深入）”；
-
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
}
真正难的是初始化依赖管理：当单例 A 依赖单例 B，而 B 又依赖 C，又需要按顺序初始化、错误传播、测试隔离时，硬编码的单例会迅速变成维护噩梦。这时候该考虑依赖注入容器（如 wire、dig），而不是继续堆砌 sync.Once。 
