应使用 sync.Once 而非全局变量+if判断实现单例，因其通过原子状态机确保初始化函数最多执行一次；若Do内panic则状态标记为已执行，后续调用不再重试，可能导致实例为nil。
为什么不用全局变量+if判断实现单例
直接用 var instance *MyStruct 加 if instance == nil 看似简单，但并发下会创建多个实例。go 调度器不保证多个 goroutine 进入临界区的顺序，两次同时判断都为 true 是常态。
实操建议：
- 永远别在无锁条件下靠
if判断初始化全局指针 - 哪怕只跑一个 goroutine，也别养成这个习惯——代码可能被复用到并发场景
-
sync.Once的底层是带原子状态机的互斥机制，它确保Do中函数最多执行一次，且后续调用直接返回
sync.Once.Do 里 panic 了怎么办
如果传给 sync.Once.Do 的函数 panic，Once 会把状态标记为“已执行”，后续调用 Do 不再运行该函数，也不会重试——也就是说，单例对象将永远为零值或未初始化状态。
常见错误现象：
立即学习“go语言免费学习笔记（深入）”；
- 调用
GetInstance()返回nil，但没报错也没日志 - 程序运行一段时间后突然某功能空指针 panic，源头却是单例初始化失败
实操建议：
- 在
Do的函数体内加defer recover()捕获 panic（仅限初始化逻辑可控时） - 更推荐方式：把初始化逻辑拆成纯函数，先校验依赖（如配置、连接），再调用
Do - 不要在
Do里做不可逆操作（如启动监听、写文件），避免失败后状态残缺
嵌入 sync.Once 的结构体如何安全导出
很多人把 sync.Once 放进结构体字段，然后导出整个结构体，结果外部能直接修改 once 字段，破坏单例语义。
使用场景：
- 需要封装初始化逻辑 + 状态字段（比如带连接池的客户端）
- 想让单例行为和业务逻辑绑定得更紧
实操建议：
-
sync.Once字段必须小写（once sync.Once），禁止导出 - 提供导出的工厂函数（如
GetClient()），内部用闭包或包级变量封装once - 若必须用结构体，初始化方法应为私有（
initClient()），且只在Do中调用一次 - 别为了“看起来面向对象”而暴露同步原语——
sync.Once不是业务字段，是初始化契约
多次调用 GetInstance 性能影响大吗
不大。sync.Once.Do 在首次执行后，后续调用只是读一个 uint32 原子变量，几乎等价于一次内存读取，没有锁竞争开销。
性能 / 兼容性影响：
- Go 1.0+ 全版本行为一致，无需担心升级 break
- 比手写
atomic.CompareAndSwapUint32更安全，也比sync.Mutex轻量得多 - 如果单例对象本身构造开销大（如加载大配置、建连接），那瓶颈在初始化逻辑，不在
Once
简短示例：
var once sync.Once var instance *DB func GetDB() *DB { once.Do(func() { instance = &DB{conn: connectToDB()} }) return instance }注意：instance 必须是包级变量，不能放在 Do 外部的局部作用域里——否则每次调用 GetDB 都新建一个 instance，那就不是单例了。
最容易被忽略的是：一旦用了 sync.Once，就等于承诺这个初始化过程不可重入、不可重试、不可取消。所有前置检查和兜底逻辑，都得在 Do 函数体内自己搞定。