sync.Once是Go中最可靠的单例实现方式，它通过运行时同步机制确保初始化函数只执行一次且线程安全；init()适合编译期无参、无错、不可变的单例；带参数或错误处理的懒加载单例需封装sync.Once并缓存结果。
Go 中 sync.Once 是最可靠的方式
单例在 Go 里不靠语言特性（比如类构造器控制），而依赖运行时同步机制。sync.Once 能保证 Do 内的初始化函数只执行一次，且线程安全——这是其他手写方式难以稳定复现的保障。
常见错误是用 if instance == nil 加锁判断，看似简单，实则存在竞态窗口：多个 goroutine 同时通过 nil 检查后，会各自进入临界区并重复初始化。
正确做法是把实例创建逻辑完全封装进 sync.Once.Do 的回调中：
var (
instance *Singleton
once sync.Once
)
func GetInstance() *Singleton {
once.Do(func() {
instance = &Singleton{}
})
return instance
}
注意：once 必须是包级变量或全局可访问的；如果定义在函数内，每次调用都会新建一个 sync.Once，失去“仅一次”的意义。
立即学习“go语言免费学习笔记（深入）”；
使用 init() 函数实现编译期单例
init() 在包加载时自动执行，天然单次、无竞态，适合初始化不可变配置对象或底层资源句柄（如数据库连接池、日志实例）。
但它有硬性限制：无法接收参数、不能返回错误、不能延迟初始化（比如依赖外部配置文件加载完成后再构建）。
典型适用场景：
- 全局日志器
log.Logger实例 - 预设的常量映射表（如 HTTP 状态码转义）
- 静态加密密钥或证书解析结果
一旦用了 init()，就放弃了运行时控制权，调试和测试也更困难——比如无法在单元测试中重置或替换该实例。
带参数/错误处理的懒加载单例（需封装 sync.Once）
真实项目中，单例初始化往往需要读配置、连数据库、校验权限，这些操作可能失败。此时不能只靠 sync.Once 原始用法，得把错误状态也纳入控制流。
关键点在于：必须缓存初始化结果（成功实例 + 错误），否则后续调用会不断重试失败路径。
推荐结构：
var (
instance *Singleton
initErr error
once sync.Once
)
func GetInstanceWithConfig(cfg Config) (*Singleton, error) {
once.Do(func() {
instance, initErr = NewSingleton(cfg)
})
return instance, initErr
}
这里 NewSingleton(cfg) 是你自己的构造函数，负责实际初始化逻辑和错误返回。注意不要在 once.Do 外再做 nil 判断或重试——那会破坏 once 的语义。
容易踩的坑：initErr 必须是包级变量，且类型为 error（不能是具体错误类型），否则无法被标准错误检查兼容。
为什么不该用 atomic.Value 或双重检查锁模拟单例
有人尝试用 atomic.LoadPointer + atomic.CompareAndSwapPointer 手写 DCL（Double-Checked Locking），但 Go 的内存模型对指针发布没有像 Java 那样明确的 happens-before 保证，容易因编译器重排或 CPU 乱序导致其他 goroutine 看到未完全初始化的对象。
atomic.Value 虽然安全，但它设计目标是“安全地替换值”，不是“确保只设置一次”。它不提供类似 sync.Once 的执行门控能力，仍需配合锁或额外状态位来防止重复初始化，反而增加复杂度和出错概率。
结论很直接：Go 标准库已经提供了 sync.Once，它经过充分验证、性能优秀、语义清晰。绕开它去手动实现，基本等于主动引入不确定性。
真正要注意的，反而是初始化函数内部是否线程安全——比如它是否调用了非并发安全的第三方库，或者是否在初始化过程中又触发了其他单例的获取，形成循环依赖。这类问题不会被 sync.Once 拦住，只能靠代码审查和运行时检测。
