sync.Once.Do中panic会导致永久失败且无法重试，正确做法是在闭包内用defer/recover捕获panic并赋值error变量，由外部函数统一返回错误供调用方检查。
sync.Once.Do 里 panic 了怎么办
sync.Once.Do 执行的闭包如果 panic，once.Do 会直接传播 panic，不会重试，也不会留下可检查的状态。这意味着：第一次调用就失败，后续所有调用都 panic——你无法区分“还没初始化”和“初始化失败”。
正确做法是把错误捕获在闭包内部，用字段显式保存失败结果：
- 声明一个
initErr error字段（与instance同级） - 在闭包里做所有初始化操作，并把错误赋给
initErr - 函数返回时统一检查
initErr，而不是依赖 panic
否则你只能靠日志猜原因，没法在上层做 errors.Is(err, fs.ErrNotExist) 这类判断。
为什么不能在 init() 里调用带 Once 的初始化函数
init() 函数本身是一次性、同步、无并发的执行时机，而 sync.Once 是为多 goroutine 竞态设计的。在 init() 里调用 once.Do 不仅冗余，还会掩盖真实问题：
- 如果初始化失败，你拿到的是
init()的 panic 堆栈，而非具体哪一行sql.Open出错 -
sync.Once的状态变量可能被编译器优化掉，或因包加载顺序导致未定义行为 - 测试时难以 mock 或跳过——
init()无法按需禁用
该做的事：把初始化逻辑全移到显式函数中，比如 app.Initialize()，再由 main() 控制调用时机。
初始化失败后还能重试吗
不能。sync.Once 的语义是“最多执行一次”，一旦 Do 返回（无论成功或 panic），它就永久标记为 done。即使你把 initErr 清空，once.Do 也不会再进闭包。
所以必须在首次调用前就做好防御：
- 检查前置条件（如配置是否存在、环境变量是否设置）再进
Do - 在闭包内用
recover()捕获可能 panic 的第三方调用（比如某些 SDK 的 NewXXX 函数） - 若业务允许，改用带重试逻辑的工厂函数，绕过
sync.Once，自己管理状态
别指望靠重置 sync.Once 字段来“重试”——它的底层字段是 unexported 的，反射修改属于未定义行为。
延迟加载遇上 context 超时怎么处理
延迟初始化函数如果要支持超时控制，不能把 context.Context 塞进 once.Do 的闭包签名里——Do 只接受 func()。正确解法是把 context 透传到初始化逻辑内部：
- 在闭包里检查
ctx.Err()，并在阻塞操作（如http.Client.Do、db.Ping）时传入 - 不要在闭包开头就
select { case ——这会让整个初始化变成“立即失败”，失去延迟意义 - 如果初始化耗时长（如下载证书、拉取远程配置），建议拆成两阶段：先快速校验本地缓存，再异步刷新
最容易被忽略的一点：sync.Once 本身不感知 context，所以超时后你得自己清理已分配但未完成初始化的资源（比如已打开但未认证的 TCP 连接），否则会泄漏。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
