Go sync 包懒加载错误缓存：初始化失败是否该重试

服务启动时读取远程配置，第一次赶上网络抖动加载失败，之后每个请求拿到的都是同一个错误——这通常不是配置中心持续故障，而是把“只初始化一次”和“失败后允许重试”混成了同一套语义。Go 的 sync.OnceValue 会缓存第一次调用的返回值，返回值里的 error 也不会例外；如果初始化失败后还允许重试，就应该把重试边界写成显式状态，而不是继续套一次性初始化器。

先看最小写法：一次性值缓存的到底是什么

下面的函数只会调用一次 loadConfig。它的返回值是一个闭包，第一次调用闭包时才真正执行加载逻辑，随后直接返回已经保存的配置和错误。

var config = sync.OnceValue(func() (*Config, error) {
    return loadConfig()
})

func handle() error {
    cfg, err := config()
    if err != nil {
        return err
    }
    return useConfig(cfg)
}

关键点在于：sync.OnceValue 不理解错误的临时性。假设第一次调用得到 nil, errNetwork，这个结果就是初始化结果的一部分。第二次调用仍然得到同一个错误，loadConfig 不会因为网络已经恢复而再次执行。

一次性值、OnceFunc 和可重试加载器不是一类工具

sync.OnceValue 适合“只要算出结果，整个进程都复用”的值，例如解析本地嵌入模板、创建不可变的正则配置或读取不会变化的构建信息。sync.OnceFunc 也是同样的一次性语义，只是它没有返回值，适合一次性注册或初始化动作。

配置中心、临时凭证和依赖健康检查通常不同：失败可能只是暂态故障，业务后续需要再次尝试。可以先把边界列清楚：

需要重试时，先把失败状态从缓存里拿出来

一个实用的最小实现是：用互斥锁保护当前配置、最后一次错误和下一次允许尝试的时间。失败只更新状态，不把失败永久标记为“已初始化”。下面的代码刻意把网络调用放在锁外，避免慢依赖阻塞读取路径。

type RetryConfig struct {
    mu      sync.Mutex
    value   *Config
    lastErr error
    nextTry time.Time
}

func (r *RetryConfig) Get(ctx context.Context) (*Config, error) {
    r.mu.Lock()
    if r.value != nil {
        value := r.value
        r.mu.Unlock()
        return value, nil
    }
    if time.Now().Before(r.nextTry) {
        err := r.lastErr
        r.mu.Unlock()
        return nil, err
    }
    r.nextTry = time.Now().Add(2 * time.Second)
    r.mu.Unlock()

    value, err := loadConfigContext(ctx)

    r.mu.Lock()
    defer r.mu.Unlock()
    if err == nil {
        r.value = value
        r.lastErr = nil
        return value, nil
    }
    r.lastErr = err
    return nil, err
}

这段代码已经覆盖三个重要逻辑：成功结果只保存一次；失败有冷却时间；调用者能看到最后一次真实错误。生产环境还应补上并发合并，否则多个请求恰好跨过冷却时间时，仍可能同时发起多次加载。

把重试边界做成可以验收的规则

这里别急着把所有错误都重试。连接超时、临时的5xx可以进入退避流程；配置格式错误、权限拒绝和证书不匹配则更适合快速失败并报警。否则重试只是把确定性故障变成持续噪声。

• 给每次加载设置独立的 context.Context，不要让一次失败占住永久后台任务。
• 记录加载开始、耗时、结果和下一次尝试时间，至少能区分“没有重试”和“重试仍失败”两种状态。
• 成功后保留旧配置还是立即替换，要按业务决定；配置切换最好做版本校验。
• 测试时覆盖首次失败、冷却期命中、下一次成功和并发读四条路径。

常见问题

一次性值返回 error 后能不能手动清空？

不能。它没有重置接口，也不建议通过重新赋值全局变量来模拟重置；这样容易和正在读取的请求产生生命周期问题。需要重试就使用显式加载器。

把一次性值放进请求函数里是不是就能重试？

那会失去跨请求复用的意义，而且每次请求都创建新的闭包。它可能看起来能重试，实际却把初始化成本重新压回了请求路径。

OnceFunc 的 panic 会不会也被记住？

会。一次性函数的调用语义包含失败状态，后续调用仍会以相同的失败结果结束。初始化动作若可能暂态失败，应该让调用方拥有重试策略。

最后的选择

只要结果成功后长期不变，sync.OnceValue 就是很干净的最小方案；只要失败有机会恢复，就不要把恢复责任交给一次性初始化器。把退避、并发合并、错误分类和观测字段写进加载器，后续排查才有抓手。