全局指针变量未初始化会导致nil panic；正确做法是声明即初始化或用sync.Once保证单次初始化，避免双重检查失效；atomic.Value不解决首次初始化问题，仅保障读写原子性。
全局指针变量在包初始化时未赋值，会导致 panic
Go 中全局指针变量（如 *sync.Once、*http.Client）若声明但未显式初始化，其零值为 nil。后续直接解引用（如 once.Do(...)）会触发 panic: runtime error: invalid memory address or nil pointer dereference。
常见于把初始化逻辑误写在函数里，而没放在 init() 或变量声明时：
- ❌ 错误：只声明不初始化 →
var once *sync.Once（此时once == nil） - ✅ 正确：声明即初始化 →
var once = new(sync.Once)或var once = &sync.Once{} - ✅ 更推荐：用
sync.Once自身控制初始化时机，而非依赖全局指针是否非空
单例模式中用 sync.Once 比单纯判断指针更可靠
仅靠 if instance == nil 做双重检查（double-check locking）在并发下不安全：多个 goroutine 可能同时通过判空，导致多次初始化。
sync.Once 保证 Do 内函数最多执行一次，且自带内存屏障，避免重排序问题：
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- ⚠️ 注意：
sync.Once必须是指针类型（*sync.Once），否则每次传参都是副本，失效 - ⚠️ 注意：被
Do包裹的初始化函数不能返回错误；如有错误需提前处理或用其他方式暴露（如初始化后检查字段） - 示例：
var ( client *http.Client once = &sync.Once{} ) <p>func GetClient() <em>http.Client { once.Do(func() { client = &http.Client{Timeout: 30 </em> time.Second} }) return client }
原子存储（atomic.Value）适合替换运行时可变的指针，但不适用于首次初始化
atomic.Value 能安全地读写任意类型（包括指针），但它本身不解决“首次初始化”的问题——它只保证读写原子性，不保证初始化只做一次。
典型误用：用 atomic.Value 替代 sync.Once 实现单例：
- ❌ 危险：多个 goroutine 同时调用
Store，谁先谁赢，但中间可能产生脏状态或资源泄漏 - ✅ 正确组合：用
sync.Once控制初始化，再用atomic.Value存储可后续更新的实例（比如热加载配置后的*Config） - 性能提示：相比互斥锁，
atomic.Value.Load()几乎无开销；但Store()是重量级操作，不应高频调用
全局变量初始化顺序影响单例行为，init() 不是万能保险
Go 的包初始化顺序由依赖图决定，init() 函数按包导入顺序执行。如果两个包都定义了单例并相互依赖，或依赖未初始化完成的变量，就会出现未定义行为。
例如：package a 中 init() 尝试调用 package b 的 NewDB()，但 b 尚未执行 init()，其内部全局变量仍是零值。
- 规避方式：推迟初始化到首次使用（即懒加载），而非放在
init()里 - 规避方式：确保单例构造不依赖其他包的全局变量，只依赖常量、字面量或参数
- 调试技巧：启动时加
-gcflags="-m"查看逃逸分析，确认单例是否意外逃逸到堆上造成隐式共享
实际项目里最常出问题的，不是不会写单例，而是把“初始化”和“线程安全访问”混成一件事来处理——前者要靠 sync.Once 或构造函数约束，后者才轮到 atomic.Value 或 sync.RWMutex 出场。
