Go Once 为什么初始化失败后不能重试

sync.Once 保证一个实例只执行一次回调，不保证“执行到成功为止”。初始化函数返回错误后，包在它外面的闭包仍已返回，Once 不会因为业务错误恢复为未执行。想允许后续重试，就要把“成功状态”和“本次失败”单独建模，而不是继续依赖同一个 Once。

我在选择懒加载写法时，会先看失败的含义：本地固定配置损坏可能适合启动失败，临时配置源不可用则可能需要恢复能力。这是方案取舍，不是某次线上事故复盘。Go 同步原语文档入口：https://pkg.go.dev/sync。

我会先问初始化失败是不是允许永久记住

以区域配置懒加载为例，我希望第一次读取失败时请求收到明确错误，依赖恢复后下一次调用可以尝试；成功取得配置后，同一实例不再重复加载。这个目标包含两个不同条件：同一时间只做一份工作，以及只有成功才永久记住结果。

Once 很适合真正不需要第二次执行的动作，却不能替应用判断错误是否临时。对我来说，代码短不等于语义合适；如果需求里明确写着“依赖恢复后自动可用”，一次尝试的缓存就是值得先排除的选项。

错误返回不会让 Once 重新变为未执行

Do 接收的回调类型是 func()，没有 error 返回位置。实际项目常用闭包把资源和 err 写到外部变量：即使 err 非空，回调也只是正常结束。在同一个 Once 上换一个闭包再次调用 Do，同样不能让它重新执行。

Go 的 Once 实现与注释说明：回调 panic 后，Do 也把这次动作视为已经返回，之后不会再次调用它。因此 recover 并不能把 Once 改造成重试器；它至多影响 panic 如何向上处理。

还有个容易被忽略的返回值问题：若每次访问函数都声明新的局部 err，但只有第一次的闭包能为它赋值，后续调用可能得到 nil 错误和未初始化资源。若业务选择永久保留第一次结果，资源和错误必须一起保存在共享状态中，并统一通过相同同步边界读取。

在三种初始化方案之间明确取舍

我不会只因为 OnceValues 能返回 error 就把它当作成功缓存。OnceValues 文档规定函数只调用一次，返回值随后复用；error 对它只是第二个普通返回值。它从 Go 1.21 提供，使用前还应考虑项目最低版本。

如果固定配置错误意味着程序不能正确服务，我更偏向启动时明确失败；如果是短暂依赖故障且业务允许请求失败后再恢复，我才选择下面的简单状态封装。没有必要为每一种初始化都统一套上同一方案。

只缓存成功结果的最小实现

下面是原创的内存配置例子。RetryConfig 用互斥锁保护 ready、cfg 和加载调用；load 在对象对外使用前固定下来，此后不并发修改。为了把重点留在初始化语义上，例子不创建连接、不读外部文件，也不进行网络请求。

package main

import (
    "context"
    "errors"
    "fmt"
    "sync"
)

type Config struct {
    Region string // 示例只返回不可变字符串，不暴露共享 map。
}

type RetryConfig struct {
    mu sync.Mutex
    ready bool
    cfg Config
    load func(context.Context) (Config, error)
}

// Get 每次最多尝试一次；失败由后续调用触发重试，不在函数内无限循环。
func (c *RetryConfig) Get(ctx context.Context) (Config, error) {
    if err := ctx.Err(); err != nil {
        return Config{}, err
    }
    c.mu.Lock()
    defer c.mu.Unlock()
    // 等锁期间可能取消；Mutex.Lock 本身不能被 context 中断。
    if err := ctx.Err(); err != nil {
        return Config{}, err
    }
    if c.ready {
        return c.cfg, nil
    }
    if c.load == nil {
        return Config{}, errors.New("未配置加载函数")
    }
    candidate, err := c.load(ctx)
    if err != nil {
        return Config{}, err // 不发布半成品，也不永久缓存本次错误。
    }
    if err := ctx.Err(); err != nil {
        return Config{}, err
    }
    if candidate.Region == "" {
        return Config{}, errors.New("加载结果缺少区域")
    }
    c.cfg = candidate
    c.ready = true // 仅在业务条件满足时发布成功状态。
    return c.cfg, nil
}

func main() {
    attempts := 0
    cache := &RetryConfig{
        load: func(ctx context.Context) (Config, error) {
            // 固定内存样例模拟首次失败，不执行外部网络请求。
            if err := ctx.Err(); err != nil {
                return Config{}, err
            }
            attempts++
            if attempts == 1 {
                return Config{}, errors.New("模拟配置暂不可用")
            }
            return Config{Region: "示例区域"}, nil
        },
    }
    for i := 1; i 

按代码可推导的预期是：第一次失败，第二次加载成功，第三次复用配置，加载次数停在 2。这是读者可自行核对的预期，不是本文的实际运行记录。示例的尝试计数只在串行 main 中展示；如果扩展为并发样例，应把诊断计数也纳入适当同步。

我喜欢这种小封装的一点，是成功条件写在赋值之前：先拿到 candidate，再检查业务字段，最后一起发布 cfg 和 ready。失败分支没有半成品可供其他调用方误用。缺点同样明显：加载时持锁，所有调用都会等待；一次失败后，排队者可能接着逐个再次加载。

我不会用重置 Once 来解决重试

不要在失败后给仍被并发使用的变量赋 sync.Once{}，也不要替换其指针就宣称旧调用已经消失。旧调用与新调用可能不属于同一轮初始化，资源与结果的归属会变得模糊。Once 使用后也不能随意复制。

如果把上面实现改成锁外加载，则必须新增“正在加载”的协调状态，让其他调用知道等待哪一轮结果；不能只是先解锁再调用 load，否则多个调用者可能同时初始化。对小型配置，我宁愿先接受清楚的持锁成本，再根据真实负载决定是否引入更复杂的协调机制。

同样不要把 ready 的读取挪到锁外作为快速路径，却不为 cfg 设计相应的发布同步。成功缓存不仅是布尔值判断，还包括它所保护的结果何时对其他调用者可见。

接入生产前还应约定什么

传了 context，就能取消所有等待吗？

不能。这个实现只在锁前和锁后检查取消，Mutex.Lock 本身不能按 context 提前退出。load 也必须自己尊重超时；若它永久阻塞，其他调用仍会等锁。需要可取消等待时，应另行设计等待通知，不应扩大宣传这个最小实现的能力。

重试间隔放在哪里？

示例没有退避、冷却期和最大次数，不能直接用于高流量下持续失败的依赖。应根据错误类型和请求预算安排冷却、带抖动退避或后台初始化；永久配置错误不宜被无限重试。失败日志还应限频，避免一次依赖故障放大为日志洪峰。

如果初始化会分配连接或临时文件呢？

load 必须清理失败或取消后未发布的资源，并明确成功资源由谁关闭。例子返回只有字符串字段的配置值，所以没有共享 map 的外部修改问题；替换成指针、切片或 map 后，还要重新约定只读、复制和关闭生命周期。

我的选择标准很简单：能够接受首次失败固定下来，才用一次性结果；需要失败后恢复，就显式建模成功状态与重试政策。Once 没有出错，错位的是“一次执行”与“成功一次”的业务预期。