Go 包变量初始化不是线程安全的
包级变量（var 声明在函数外）的初始化表达式，在 init() 函数执行前就求值——但这个过程本身不加锁，多个 goroutine 同时首次访问未初始化完成的包变量时，可能触发重复初始化或读到零值。
典型现象：某个包里定义了 var cache = buildExpensiveMap()，服务刚启动时偶发 panic 或返回空 map，尤其在高并发 HTTP handler 中高频调用该变量时更明显。
根本原因不是 Go 语言 bug，而是包初始化只保证「单次执行」，不保证「执行期间对其他 goroutine 可见」——它依赖于 Go 运行时的 init 顺序机制，而非内存屏障或同步原语。
- 如果初始化逻辑无副作用、纯函数式（如
var x = 42），没问题 - 一旦涉及 I/O、反射、goroutine 创建、或调用其他包的未初始化变量，风险陡增
-
sync.Once是最轻量且推荐的兜底方案，不是“过度设计”
用 sync.Once 替代包变量直接初始化
把昂贵/非幂等的初始化逻辑从包变量声明中剥离，改用惰性+原子控制。这不是绕弯子，是明确告诉运行时：“这个动作只许做一次，且做完才允许别人读”。
立即学习“go语言免费学习笔记（深入）”；
常见错误写法：var client *http.Client = newHTTPClient() —— 如果 newHTTPClient() 内部用了 time.Now() 或读配置文件，就可能被多 goroutine 并发调用多次。
正确做法是把初始化封装进函数，并用 sync.Once 控制入口：
var (
client *http.Client
once sync.Once
)
func getHTTPClient() *http.Client {
once.Do(func() {
client = newHTTPClient()
})
return client
}
- 必须把
sync.Once和目标变量放在同一包作用域，不能藏在函数内部 - 不要试图用
atomic.Value替代sync.Once来做初始化——atomic.Value解决的是「读写并发安全」，不是「初始化仅一次」 - 如果初始化失败需要重试，
sync.Once不支持，得自己封装带错误返回的 once 类型
atomic.Value 适合已初始化后的并发读写，不适合初始化阶段
atomic.Value 的定位很清晰：在变量**已经完成初始化之后**，提供无锁的、类型安全的读写切换能力。它不参与“第一次赋值”的协调。
典型误用场景：想用 atomic.Value.Store() 在包初始化时存一个 map，然后多个 goroutine 调 Load()——这看似安全，但没解决“谁来负责第一次 Store()”的问题。如果多个 goroutine 同时发现值为空，都去执行初始化并 Store()，就会浪费资源甚至引发竞态。
-
atomic.Value的Store()和Load()是并发安全的，但初始化逻辑本身不在其保护范围内 - 它适合热更新配置、切换连接池实例、替换缓存策略等「运行时变更」场景，不是包加载期的救命稻草
- 和
sync.Once搭配用是常见模式：Once 负责首次构建 + Store，Value 负责后续快速 Load
init() 函数里做初始化也不等于线程安全
很多人以为把初始化逻辑塞进 func init() 就万事大吉。其实不然：init() 确保只执行一次，但它执行时机由导入顺序决定，且**不阻塞其他包的 init 执行**。如果 A 包的 init() 依赖 B 包的某个变量，而 B 包的 init() 还没跑完，A 就可能读到零值。
更隐蔽的问题是：init() 执行期间，其他 goroutine 已经可以运行（比如 main 启动了 goroutine，或测试框架提前触发了某些 handler）。这时若这些 goroutine 访问尚未完成 init 的包变量，就会踩坑。
- 不要在
init()里起 goroutine 做异步初始化（除非你手动用 channel 或sync.WaitGroup同步完成信号） - 避免跨包强依赖初始化顺序；优先用显式初始化函数 +
sync.Once替代隐式 init 依赖 - 单元测试中容易暴露这类问题：test goroutine 和 init 可能竞争，建议用
go test -race跑一遍
初始化这件事，Go 给你的是“单次语义”，不是“原子可见性”。想安全，就得自己补上那道 fence。
