sync.once.do传入函数panic后永远失效，因done字段被原子置1且不可逆，不捕获panic也不重试；须在闭包内defer/recover或改用error返回路径，并避免闭包捕获外部可变变量。
sync.Once 不是“懒加载万能胶”，它只管函数体执行一次，不管初始化成不成功、变量安不安全、后续用不用得对。
sync.Once.Do 为什么传函数会 panic 后就永远失效
因为 panic 发生时，sync.Once 内部的 done 字段（uint32）已被原子设为 1，状态不可逆。它不捕获 panic，也不重试，更不会回滚标记。
- 现象：初始化数据库连接失败 panic → 后续所有
once.Do(initDB)都静默跳过 →db变量始终为 nil - 正确做法：在传入函数里用
defer recover()捕获 panic，并显式记录错误，例如写入包级initErr error变量 - 更稳妥方式：把初始化逻辑封装成返回
error的函数，再由Do调用，失败后靠外层判断处理
闭包捕获变量导致的“看似一次，实则错乱”
传给 Do 的闭包若直接引用循环变量或外部可变状态，所有 goroutine 共享同一份地址，结果不可预测。
- 错误写法：
for i := 0; i → 极大概率输出三个 <code>3 - 正确写法一（立即求值）：
once.Do(func(v int) { fmt.Println(v) }(i)) - 正确写法二（绑定副本）：
val := i; once.Do(func() { fmt.Println(val) }) - 强烈建议：抽成独立函数，如
initWithID(i)，避免闭包语义模糊
sync.Once 和变量读写安全完全无关
sync.Once 只保证 Do 里的函数最多跑一次，它不提供任何对初始化后变量的并发访问保护。
- 典型误用：
once.Do(func() { cache = make(map[string]int) })→ 后续并发cache["k"] = v会触发fatal error: concurrent map writes - 必须配套使用：
sync.RWMutex（读多写少）或sync.Mutex（写频繁），读写操作都要加锁 - 别混淆
sync.Once和sync.Map：后者是线程安全 map，前者连 map 都不是
测试中反复调用 Do 总是跳过？你复制了 sync.Once
sync.Once 是值类型，一旦被复制（作为 struct 字段、函数参数、map value），每个副本都独立维护 done 状态，原意就全废了。
- 错误姿势：
type Config struct { once sync.Once }→ 每次new(Config)都拿到新once，毫无意义 - 正确姿势一：声明为包级变量，如
var loadConfigOnce sync.Once - 正确姿势二：结构体中存指针，
type DB struct { once *sync.Once }，初始化时赋值new(sync.Once) - 单元测试时，别在 test helper 里复用全局
once；改用局部变量或重置依赖项
最容易被忽略的是：sync.Once 的“一次”仅针对它自己那个 Do 调用，不是针对业务语义上的“首次使用”。初始化逻辑和后续使用逻辑边界一旦模糊，比如在 Do 里启动 goroutine 却没等它结束，就以为资源 ready 了——这时候出问题，sync.Once 不背锅，它只负责关门，不管门后有没有人站稳。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
