延迟加载字段若可变，必须用sync.Once配合sync.RWMutex保护，避免并发读写冲突；只读字段仅需sync.Once。
延迟加载字段的并发读写冲突
Go 中延迟加载（lazy init）最常见写法是用 sync.Once，但它只解决“初始化一次”问题，不保护后续对已初始化字段的并发读写。比如一个延迟构建的 map[string]int，一旦初始化完成，多个 goroutine 直接读写它就会触发 data race。
典型错误现象：fatal error: concurrent map writes 或 unexpected fault address，pprof 检测出大量 runtime.mapassign 竞争。
- 若字段只读（如配置结构体），初始化后无需加锁，
sync.Once足够 - 若字段可变（如缓存
map、切片、计数器），必须搭配sync.RWMutex或原子操作 - 避免把
sync.Mutex嵌入结构体后直接复制——复制会破坏锁状态，应始终传指针
用 sync.Once + RWMutex 组合保护可变延迟字段
这是最常用也最稳妥的组合：用 sync.Once 保证初始化仅一次，用 sync.RWMutex 控制后续读写。读多写少场景下，读锁开销极低，比全用 Mutex 高效得多。
示例：
立即学习“go语言免费学习笔记（深入）”；
type LazyCache struct {
once sync.Once
mu sync.RWMutex
data map[string]int
}
func (c *LazyCache) Get(key string) int {
c.mu.RLock()
defer c.mu.RUnlock()
return c.data[key]
}
func (c *LazyCache) Set(key string, val int) {
c.mu.Lock()
defer c.mu.Unlock()
c.data[key] = val
}
func (c *LazyCache) init() {
c.data = make(map[string]int)
}
func (c *LazyCache) Load() {
c.once.Do(c.init)
}
注意：必须在 init() 中完成全部字段赋值，不能在 Do 外部再修改 c.data，否则破坏 once 的语义。
避免 sync.Once 在热路径上成为瓶颈
sync.Once 内部用原子操作+互斥锁实现，在高并发初始化场景下（如每秒数万次调用 Load()），可能因锁竞争拖慢性能。这不是 bug，而是设计使然——它本就不该出现在高频调用路径里。
- 初始化逻辑本身不应含耗时操作（如网络请求、文件 IO），否则会阻塞所有等待者
- 如果初始化成本高且调用频繁，考虑预热：在程序启动时主动调用一次
Load() - 极端场景可改用原子指针（
unsafe.Pointer）+ CAS 实现无锁初始化，但需严格保证内存可见性，不推荐新手使用
全局延迟加载 vs 实例级延迟加载
很多人混淆了两种粒度。全局延迟加载（如 var cache = newLazyCache()）只需一份 sync.Once；而每个结构体实例都带延迟字段（如每个 HTTP handler 实例有自己的缓存），则每个实例都要独立的 once 和 mu。
容易踩的坑：
- 把
sync.Once声明为包级变量却用于多个不同对象的初始化——会导致后初始化的对象跳过自己的初始化逻辑 - 在方法中用局部
sync.Once变量——每次调用都新建，完全失去“once”意义 - 用
init()函数替代延迟加载——失去按需加载优势，且无法处理依赖 runtime 状态的初始化（如读取环境变量、连接池）
真正需要关注的，从来不是“怎么写延迟加载”，而是“这个字段是否真的需要延迟”以及“它被多少 goroutine 共享”。多数情况下，提前初始化或用 sync.Pool 替代延迟更简单安全。
