defer 完全不适用字典表加载，因其仅在函数返回时执行，无法满足服务启动后、首次查询前就需就绪的要求；sync.Once 配合懒加载结构体才是唯一安全方案。
不能用 defer 延迟加载字典表，它只在函数退出时执行，而字典数据通常需要在服务启动后、首次查询前就准备好；应使用 sync.Once 配合懒加载结构体。
为什么 defer 完全不适用
defer 的执行时机是「所属函数返回时」，和系统字典的加载需求天然错位：
- 字典表要供全局 HTTP handler 或业务逻辑随时查，不是某个函数内部的临时资源
-
defer绑定在某次调用作用域里，无法跨 goroutine 共享实例 - 如果写在
init()里用defer，那它会在包初始化结束时立刻触发——根本没延迟 - 更危险的是：若字典加载失败，
defer会静默吞掉错误，后续调用直接 panic
sync.Once 是唯一安全的延迟加载方案
它保证初始化逻辑最多执行一次，且线程安全，适合多 goroutine 并发首次访问场景：
- 定义一个带
sync.Once和缓存字段的结构体，比如type DictLoader struct { data map[string]any; once sync.Once; err error } -
Load()方法里调用p.once.Do(p.init)，把数据库查询或文件读取逻辑放在init函数中 - 首次调用
Load()时才真正查库，之后所有调用都直接返回缓存结果 - 务必把错误
err存为字段，避免重复尝试失败操作
func (d *DictLoader) Load() (map[string]any, error) {
d.once.Do(d.init)
return d.data, d.err
}
func (d *DictLoader) init() {
rows, err := db.Query("SELECT key, value FROM sys_dict WHERE type = ?", "status")
if err != nil {
d.err = err
return
}
defer rows.Close()
d.data = make(map[string]any)
for rows.Next() {
var k, v string
if err := rows.Scan(&k, &v); err != nil {
d.err = err
return
}
d.data[strings.TrimSpace(k)] = v
}
}
加载时机必须和配置生命周期对齐
字典数据依赖配置（如 DB 连接、环境标识），所以不能塞进 init() —— 那时 viper 或其他配置还没 ready：
立即学习“go语言免费学习笔记（深入）”；
- 主程序完成
viper.ReadInConfig()和 DB 初始化后，显式调用一次dictLoader.Load()（可选，用于预热） - 但不要阻塞启动：让第一次业务请求触发加载，只要确保
Load()方法本身能处理并发即可 - 避免在
init()中调用任何外部依赖（DB、HTTP client、viper.Get），否则测试时无法 mock，启动顺序也失控 - 如果字典需支持热更新，额外加一层
time.Ticker+ 版本号比对，但这是另一层复杂度，和延迟加载无关
容易被忽略的坑：nil 指针与空 map
很多人写 if d.data == nil { d.load() } 来模拟延迟，这在并发下会崩溃：
- 多个 goroutine 同时看到
d.data == nil，全部进入load()，导致重复查询甚至连接耗尽 - 未加锁的 map 赋值在并发写时 panic（Go runtime 直接 abort）
- 正确做法只有两个：用
sync.Once，或者用sync.RWMutex+ 双检锁（不推荐，易出错） - 初始化失败后，
d.data是 nil，但d.err已设，后续调用应直接返回该错误，而不是再次尝试
