最可靠方式是 sync.once：它用原子操作+轻量互斥确保初始化函数只执行一次，所有 goroutine 等待完成，避免双重检查遗漏、半初始化对象等问题。
Go 里用 sync.Once 实现线程安全单例最可靠
直接结论：别手写锁、别用 init()、别靠 if instance == nil 判断——唯一推荐方式是 sync.Once。它底层用原子操作+轻量级互斥，保证 Do 里的函数只执行一次，且所有 goroutine 等待直到初始化完成。
常见错误现象：nil 检查 + mutex.Lock() 套路看似合理，但容易漏掉双重检查（double-check）的第二层判断，或忘记在加锁前先判空，导致多个 goroutine 同时进入临界区；更隐蔽的是，即使加了锁，如果构造函数本身有副作用（比如启动 goroutine、打开文件），没同步等待就返回实例，调用方可能拿到“半初始化”的对象。
-
sync.Once自动处理“谁触发初始化、谁等待结果”，无需手动管理状态 - 初始化函数必须无参数、无返回值，所以要把依赖提前准备好（比如配置、连接池）
- 一旦
Once.Do()执行过，后续调用不阻塞、不重试，哪怕初始化函数 panic 了，也不会再执行第二次（这点要小心）
示例：
var (
instance *DB
once sync.Once
)
func GetDB() *DB {
once.Do(func() {
instance = &DB{conn: openConnection()}
})
return instance
}
为什么不用 init() 做单例？
init() 确实只运行一次，但它在包加载时就执行，无法按需延迟初始化，也不支持传参或错误处理。很多单例依赖外部配置、环境变量或网络资源，init() 里做这些会把启动失败变成 panic 或静默失败，调试困难。
在 Golang 中使用 samber/hot 进行内存缓存，支持 LRU、LFU、TinyLFU、W‑TinyLFU、S3FIFO、ARC、TwoQueue、SIEVE、FIFO 等淘汰算法，提供 TTL、缓存加载器及分片功能。
- 无法捕获初始化错误（比如数据库连不上），只能 log 或 panic，没法向上抛错
- 测试时难 mock：你没法在测试中跳过
init()或替换它的行为 - 如果单例构造开销大（比如加载大模型、预热缓存），而程序大部分路径根本用不到它，
init()就白白拖慢启动
带错误返回的单例怎么写？
sync.Once 的 Do 不接受返回值，所以不能直接返回 error。常规做法是把 error 存到包级变量，并在首次调用 GetXXX() 时检查。
- 必须用指针或接口类型存储 error，否则值拷贝会导致判断失效
- 调用方拿到
nil实例时，要主动检查错误变量，不能假设“没 panic 就成功” - 避免在
once.Do外再加一层锁来保护 error 变量——sync.Once本身已保证执行顺序，只需保证 error 赋值是原子的（*error赋值是安全的）
示例：
var (
instance *Client
initErr error
once sync.Once
)
func NewClient(cfg Config) (*Client, error) {
once.Do(func() {
c, err := newClient(cfg)
instance = c
initErr = err
})
return instance, initErr
}
并发下多次调用 GetXXX() 会不会卡住？
不会。只有第一个调用者会执行初始化函数，其余 goroutine 会阻塞在 once.Do() 内部，等初始化完成立刻返回，不重复执行也不额外加锁。压测中上万 goroutine 同时调 GetDB() 是常态，sync.Once 表现稳定。
- 注意别在初始化函数里做耗时操作（比如同步 HTTP 请求、大文件读取），否则所有等待 goroutine 都卡住
- 如果初始化本身需要超时控制，得在外层加 context，不能指望
sync.Once提供 - 某些极端场景（比如初始化函数 panic），
sync.Once会记录“已执行”，后续调用直接返回，此时instance可能是nil，必须配合错误检查
真正容易被忽略的是：单例对象内部状态是否线程安全。比如一个 map 字段，即使创建是单例的，后续并发读写仍需自己加锁或换用 sync.Map ——sync.Once 只保创建，不保使用。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
