sync.Once 是唯一推荐的单例实现方式，因其通过原子操作与轻量锁确保初始化函数仅执行一次、内存可见且阻塞等待；其他方式存在竞态、死锁、重排或性能问题。
sync.Once 是唯一推荐方式，其他写法要么不安全，要么难维护，要么性能差。
为什么不能只用 if instance == nil 判断
因为 if 本身不是原子操作。多个 goroutine 同时执行时，可能都看到 instance == nil，然后各自执行初始化逻辑——结果创建出多个实例。
- 常见错误现象：
Singleton instance created multiple times、数据库连了两次、日志里看到初始化逻辑被执行多次 - 即使加了
sync.Mutex，也容易漏掉第二层判空（即没做双重检查），或忘记defer mu.Unlock()导致死锁 - 手动加锁无法保证内存可见性：一个 goroutine 写完
instance，另一个可能读到未完全构造的对象（编译器/CPU 指令重排） - 每次调用都要抢锁，性能比
sync.Once差不少
sync.Once 怎么用才不出错
sync.Once 底层用原子操作 + 轻量互斥锁，确保 Do 里的函数只执行一次，且所有并发调用者会阻塞等待初始化完成，而不是各自返回 nil 或旧值。
- 必须把
instance声明为包级私有变量（小写开头），不能导出；只通过GetInstance()访问 -
once.Do()的闭包里必须直接赋值给包级变量，比如instance = &MyService{}，不能在闭包内声明新变量 - 如果初始化可能失败（如打开数据库连接），需额外声明
err error包级变量，在once.Do闭包中一起赋值 -
once.Do不重试：一旦初始化函数 panic，状态被标记为“已完成”，后续调用直接跳过，instance和err都保持 panic 前的值
带错误返回的单例怎么写
sync.Once.Do 签名是 func(f func())，不支持返回值。所以不能靠它直接暴露错误，必须配合包级 err 变量。
- 声明
var err error（注意是值类型，不是指针；error接口赋值本身是线程安全的） - 在
once.Do闭包中调用初始化函数，同时赋值instance和err - 对外提供
GetInstance() (*MyService, error)，调用方必须检查返回的error，不能假设“没 panic 就成功” - 不要在
once.Do外再加锁保护err——sync.Once已保证执行顺序，多 goroutine 同时读err是安全的
什么时候不该用单例
单例不是银弹。它天然引入全局状态，会抬高测试和重构成本。
立即学习“go语言免费学习笔记（深入）”；
- 如果服务需要 mock（比如单元测试中替换 DB 实例），单例会让测试变复杂，此时应考虑依赖注入
- 如果初始化依赖运行时参数（如命令行 flag、环境变量），但又想复用同一份代码在不同配置下启动多个实例，单例就违背设计初衷
- 如果结构体本身无状态、构造极轻量（比如纯数据容器），没必要套单例，直接
&MyStruct{}更清晰 - 真正适合单例的场景很明确：数据库连接池、日志实例、全局缓存管理器、配置加载器——这些对象开销大、需全局唯一、且生命周期与程序一致
sync.Once 对 panic 的处理是“永久标记完成”，这点容易被忽略：一旦初始化失败，后续调用永远拿不到新实例，也看不到新错误。得靠上层主动重启或提前校验依赖。 
