Go sync.Once 失败后为什么不会自动重试：初始化错误缓存与恢复写法

线上服务把远程配置加载放进 sync.Once 后，第一次网络抖动就可能留下一个很难解释的状态：初始化函数返回了错误，后续请求却再也不尝试加载。原因不在网络库，而在 sync.Once 的承诺——它只保证函数最多执行一次，不保证这一次一定成功。

先看一个会把错误记住的最小例子

假设服务第一次请求配置中心时可能超时。下面的写法看起来很自然，但 loadErr 一旦被写入，后面的调用只会读取同一个错误。

var (
    once   sync.Once
    config AppConfig
    loadErr error
)

func Config() (AppConfig, error) {
    once.Do(func() {
        config, loadErr = loadFromConfigCenter()
    })
    return config, loadErr
}

这里没有“错误缓存策略”这一层，只有一次性执行器。第一次调用若遇到 context deadline exceeded，once.Do 仍然会正常返回；它不会观察 loadErr 并替你重置内部状态。

旧代码与可恢复写法的边界不同

如果配置必须在进程启动时存在，失败后直接退出往往最清楚：让编排系统重启进程，避免半初始化服务接收流量。这个场景适合保留 sync.Once，但要把错误尽早暴露。

如果配置中心短暂不可用、服务仍能提供降级能力，就不应把可重试任务塞进 sync.Once。可以用互斥锁保护当前值和加载状态，成功后缓存结果，失败时允许下一次调用重新加载：

type ConfigStore struct {
    mu     sync.Mutex
    value  AppConfig
    ready  bool
    lastErr error
}

func (s *ConfigStore) Get(ctx context.Context) (AppConfig, error) {
    s.mu.Lock()
    defer s.mu.Unlock()

    if s.ready {
        return s.value, nil
    }

    value, err := loadFromConfigCenterWithContext(ctx)
    if err != nil {
        s.lastErr = err
        return AppConfig{}, fmt.Errorf("load config: %w", err)
    }
    s.value = value
    s.ready = true
    s.lastErr = nil
    return s.value, nil
}

这个版本的关键不是“加一把锁”，而是只有成功才把 ready 设为 true。失败路径不改变成功状态，下一次调用自然还有机会重新加载。

并发请求多时，别把重试写成请求风暴

上面这种简单写法会把加载逻辑串行化，如果第一次调用耗时很长，后续所有请求都要排队等它执行完；如果第一次直接失败了，后续进来的请求又有可能各自发起多次加载动作，把下游服务打穿。上生产之前最好把重试间隔、超时时长、最大并发尝试次数这些规则都明确定义出来。

如果使用 singleflight.Group 把同一时间窗口的加载合并起来，也要确认失败结果不会被当成永久初始化结果。单航班解决的是并发合并，不会改变失败是否可重试的业务语义。

如果必须坚持 sync.Once，错误应该在哪里处理

常见做法是让 Do 内部只执行不可失败的内存初始化，把可能失败的网络、磁盘和凭据检查放到显式的启动阶段：

var once sync.Once
var defaults AppConfig

func defaultConfig() AppConfig {
    once.Do(func() {
        defaults = AppConfig{Timeout: 2 * time.Second}
    })
    return defaults
}

func Start(ctx context.Context) error {
    cfg := defaultConfig()
    remote, err := loadFromConfigCenterWithContext(ctx)
    if err != nil {
        return fmt.Errorf("startup config check: %w", err)
    }
    applyConfig(cfg, remote)
    return nil
}

这样 sync.Once 管的是确定性默认值，启动阶段管的是可能失败的外部依赖。若业务要求不停机恢复，则把 Start 改成独立的后台加载流程，并增加可观测的状态转换。

用测试确认失败后确实还能恢复

测试的时候别只验证“第二次调用能拿到正确配置”这一种场景，必须先构造第一次加载明确失败的用例，同时统计初始化函数的实际执行次数，不然不符合预期的测试Mock很容易把状态没正确重置的bug给掩盖过去。

func TestConfigStoreRetriesAfterFailure(t *testing.T) {
    var calls atomic.Int32
    store := ConfigStore{}
    load := func(context.Context) (AppConfig, error) {
        if calls.Add(1) == 1 {
            return AppConfig{}, errors.New("temporary outage")
        }
        return AppConfig{Timeout: time.Second}, nil
    }

    // 将 store 的加载函数注入为 load，第一次调用断言失败，
    // 第二次调用断言成功，并确认 calls == 2。
}

真实项目里可以把加载函数作为 ConfigStore 字段注入，避免测试依赖全局函数。还应增加并发测试：多个 goroutine 同时读取时，成功配置不能出现半写入状态。

相关问题：什么时候该用 sync.Once

配置加载失败后能不能手动重置 sync.Once？

不要为了实现重试直接去替换全局变量，或者靠复制内部字段的方式强行修改状态。把支持重试的初始化流程封装成显式的加载器状态机，语义清晰安全，后续做单元测试也方便很多。

sync.Once 能保证初始化结果对其他 goroutine 可见吗？

能。Do 返回后，其他 goroutine 能看到函数内完成的写入；但它只保证执行顺序和可见性，不保证初始化函数返回成功。

连接池初始化失败也适合 sync.Once 吗？

这个选择完全看组件的生命周期要求。如果是进程启动阶段必须完成初始化的核心连接池，失败直接退出进程就好；如果是运行过程中允许断线重连的组件，最好单独实现带重试能力的连接管理器，把内部状态、退避策略、异常告警这几块逻辑单独抽出来设计。

最后用三项检查收口

看到 sync.Once 包住外部依赖时，先问三个问题：失败后是否允许重试？错误是否会被监控看到？并发调用时是否会把一次故障放大成大量请求？如果第一问的答案是“允许”，就不要把重试语义寄托在 sync.Once 上；让成功缓存、失败恢复和并发合并各自承担清晰职责。