能，但仅限初始化无副作用且不依赖外部状态的场景；sync.Once 是确保代码只执行一次的轻量原语，失败后不可重试，适合配置加载等终态操作。
Go 里 sync.Once 真的能安全实现单例吗？
能，但只在「初始化逻辑无副作用、不依赖外部状态」的前提下成立。它不是万能锁，也不是替代 sync.Mutex 的通用方案，而是专为「确保某段代码仅执行一次」设计的轻量原语。
常见错误是把它当“懒汉式双重检查锁”用——比如在 GetInstance() 里反复调用 once.Do() 却没意识到：一旦初始化失败（panic 或未完成），sync.Once 就永远卡死，后续调用直接阻塞或 panic。
-
sync.Once内部用的是原子状态机，不是互斥锁，所以没有“可重入”或“超时取消”能力 - 初始化函数如果 panic，
sync.Once会把 panic 向上传播，且标记为“已执行”，后续调用不再尝试 - 适合场景：全局配置加载、数据库连接池初始化、日志实例创建等「成功即终态」的操作
为什么不用双重检查锁定（Double-Check Locking）？
Go 不需要手动写 DCL —— 因为 sync.Once 本身就是语言层面对该模式的标准化封装，且更安全、更简洁。自己手写 DCL 容易出错，比如：
- 忘记用
sync/atomic读写标志位，导致指令重排（Go 编译器和 CPU 都可能乱序） - 在
if instance == nil和加锁之间被抢占，多个 goroutine 同时进入临界区 - 初始化完成后没用
atomic.StorePointer写回指针，其他 goroutine 看不到新值
而 sync.Once 内部已用 atomic.LoadUint32 + atomic.CompareAndSwapUint32 保证顺序与可见性，你只需专注初始化逻辑本身。
立即学习“go语言免费学习笔记（深入）”；
sync.Once 初始化失败后怎么恢复？
不能恢复。这是它的设计契约：「最多执行一次，无论成败」。如果你的初始化可能失败（比如网络请求超时、文件不存在），必须在外层兜底，而不是指望 once.Do() 重试。
- 把初始化逻辑包装成带返回值的函数，先预检再调用
once.Do() - 用额外变量记录状态，例如
var err error和var instance *MyService，在Do()函数里赋值并捕获 panic - 避免在
Do()回调里做不可逆操作（如打开文件句柄但不关闭），否则失败后资源泄漏
示例：
var (
once sync.Once
instance *DB
initErr error
)
func GetDB() (*DB, error) {
once.Do(func() {
db, err := connectDB()
if err != nil {
initErr = err
return
}
instance = db
})
return instance, initErr
}
并发调用 GetDB() 时性能如何？
首次调用有明显开销（原子操作 + 可能的锁竞争），之后全是原子读，几乎零成本。实测在 1000+ goroutine 并发下，热路径耗时稳定在纳秒级。
- 比每次加
sync.Mutex快 3–5 倍（尤其高并发时） - 比手写 DCL 更省心，也避免了误用
volatile类语义带来的隐患 - 注意：不要在热循环里反复调用
once.Do()，哪怕只是空函数——原子操作仍有代价
真正容易被忽略的是：初始化函数里的任何阻塞操作（比如 time.Sleep、未设 timeout 的 HTTP 请求）都会拖慢所有等待中的 goroutine，而且无法中断。
