sync.Once.Do 不会重复执行，因其用 uint32 原子变量+CompareAndSwapUint32 实现无锁等待，仅首个 goroutine 执行函数，其余等待完成；若函数 panic，状态仍置为已完成，错误被静默吞掉。
sync.Once.Do 为什么不会重复执行
sync.Once 内部用一个 uint32 原子变量标记是否已执行，配合 sync/atomic.CompareAndSwapUint32 实现“仅一次”语义。它不依赖锁来阻塞后续调用，而是让所有未命中者等待首个调用者完成——这是它比 sync.Mutex + 手动 flag 更高效的关键。
常见误判是认为 Do 会阻塞并发调用直到返回，其实它只阻塞“尚未看到执行完成”的 goroutine；一旦内部标志置为 1，后续所有调用立刻返回，不进入同步路径。
传给 sync.Once.Do 的函数不能有 panic
如果传入的函数在执行中 panic，sync.Once 仍会将内部状态标记为“已完成”，后续调用不再执行该函数，但也不会恢复 panic —— 这意味着错误被静默吞掉，且初始化逻辑实际失败了。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 务必在传入函数内用
defer/recover自行捕获 panic，并记录日志或返回错误 - 避免在
Do中调用可能 panic 的第三方库初始化（如未校验的 JSON 解析、空指针解引用） - 若需传播错误，应在外层封装：用
sync.Once控制执行时机，把结果缓存在包级变量中，panic 或 error 由调用方检查
多个 sync.Once 实例不能共享“单次”语义
每个 sync.Once 是独立实例，哪怕它们调用同一个函数，也不构成互斥。例如：
var once1, once2 sync.Once once1.Do(initDB) // 执行 once2.Do(initDB) // 也会执行
典型踩坑场景：
- 在 struct 方法里定义
once sync.Once字段，以为能保证“每个实例只初始化一次”，但其实是“每个字段实例只执行一次”，和业务意图常不一致 - 误以为包级变量 + 多个
sync.Once可以分阶段控制初始化，结果各干各的 - 正确做法：按逻辑边界划分，一个初始化动作对应一个
sync.Once实例，且该实例生命周期要覆盖所有需要它的调用点（通常是包级变量）
sync.Once 不适合做带参数的懒加载
sync.Once.Do 只接受 func()，无法传参。想实现“首次访问 key 时初始化对应 value”，不能靠一个 sync.Once 解决。
替代方案取决于场景：
- 固定几个 key → 提前声明多个
sync.Once实例（如onceA,onceB） - 动态 key → 改用
sync.Map+ CAS 风格检查，或用读写锁保护 map + 初始化逻辑 - 初始化成本高且 key 稀疏 → 考虑用
singleflight.Group防止缓存击穿，它天然支持参数化调用
容易忽略的是：sync.Once 的设计目标非常窄——就是“全局、无参、仅一次”。超出这个范围硬套，反而增加竞态风险或掩盖真实需求。
