syncOnceValue缓存panic后的行为是什么

会。sync.OnceValue 的初始化函数第一次执行时如果发生 panic，返回的函数不会在下一次调用时重试，而是继续 panic 同一个值。它把“初始化失败”当成一次性结果的一部分缓存下来。

官方地址：https://pkg.go.dev/sync#OnceValue

如果初始化逻辑可能暂时失败，不能直接把它包进 sync.OnceValue 后期待下次调用自动恢复。要么把失败作为 error 返回，要么在更外层明确设计重试和重新创建闭包的策略。

第一次 panic 后，第二次仍然会 panic

下面这个例子里，load 只会进入一次。第一次调用触发字符串 panic；第二次调用不会再次执行 load，但仍会收到同一个 panic 值。

package main

import (
    "fmt"
    "sync"
)

func main() {
    calls := 0
    load := sync.OnceValue(func() string {
        calls++ // 这个计数只用于说明初始化函数不会被重试
        panic("配置中心暂时不可用")
    })

    for i := 1; i 

这里的关键不是调用方是否用了 recover，而是 OnceValue 自己已经把这次失败固定下来。recover 只能让当前调用继续运行，不能清空闭包中的一次性状态。

为什么 panic 会被记住

标准库实现用一次性同步状态保护初始化函数，并额外保存了一个 valid 标志和一个 panic 值容器。只有函数正常返回时，valid 才会变成 true；如果函数 panic，状态保持为无效，同时保存 panic 值。后续调用发现状态无效，就再次抛出保存的值。

这带来两个容易忽略的结论：

• 并发调用也不会让多个 goroutine 同时执行初始化函数；只有一次调用负责执行，其他调用看到同一结果。
• 失败不会退化成“下一次再试一次”。对外暴露的闭包仍然是同一个失败结果。

如果初始化成功，返回值会被缓存；如果初始化 panic，panic 值也会被缓存。二者共同组成了 OnceValue 的一次性语义。

需要可恢复时，把失败改成 error

如果失败属于配置错误、永久不可用或不应重复尝试的状态，可以让 panic 自然暴露；但对网络、远端配置、临时文件等可能恢复的依赖，更适合用 sync.OnceValues 返回值和 error。注意：这仍然只执行一次，但调用方能用普通错误分支处理失败。

var loadConfig = sync.OnceValues(func() (Config, error) {
    cfg, err := readConfig() // 把可预期失败放进 error，而不是 panic
    if err != nil {
        return Config{}, err // error 也会作为一次性结果保存
    }
    return cfg, nil
})

func config() (Config, error) {
    cfg, err := loadConfig()
    if err != nil {
        return Config{}, fmt.Errorf("读取配置失败: %w", err) // 保留原始错误便于定位
    }
    return cfg, nil
}

OnceValues 不是重试器。若第一次返回 error，之后调用仍会得到同一组结果。它解决的是“不要用 panic 表示普通失败”，而不是“失败后再次请求”。

确实要重试，就重建一次性闭包

重试必须是显式策略。例如可以让一个管理对象在外层保存当前的加载函数，失败后由受控操作创建新的 sync.OnceValue。不要试图修改闭包内部的 sync.Once，也不要在多个 goroutine 中无保护地替换函数。

type Loader struct {
    mu   sync.RWMutex
    load func() Config
}

func (l *Loader) Reset() {
    l.mu.Lock()
    defer l.mu.Unlock() // 用同一把锁保护闭包替换
    l.load = sync.OnceValue(func() Config {
        return fetchConfigOrPanic() // 新闭包才代表一次新的初始化尝试
    })
}

func (l *Loader) Load() Config {
    l.mu.RLock()
    load := l.load // 复制函数值后再调用，避免持读锁执行慢操作
    l.mu.RUnlock()
    return load()
}

这个模式的重试入口必须有清晰的触发条件、并发控制和失败上限。若远端依赖本身适合退避重试，通常应在 fetchConfigOrPanic 之外使用带超时的请求重试，而不是每个调用方都重建闭包。

三个边界别混在一起

另外，panic(nil) 的表现会受 Go 版本和运行时设置影响，不建议把它当成区分“是否发生 panic”的可靠信号。业务代码最好使用明确的错误值或非 nil 的 panic 值，并把恢复边界放在真正负责决策的层。

常见追问

sync.OnceValue 会缓存 panic 的堆栈吗？ 它保证的是后续调用继续 panic 同一个值；首次调用和后续调用的栈信息由各自的调用位置决定，不应把它当成完整的首次堆栈快照。

recover 后能让 OnceValue 再执行吗？ 不能。recover 只处理当前 goroutine 的当前 panic，不能重置 OnceValue 的内部状态。

想让每次请求都能重试怎么办？ 不要把请求级临时失败直接交给 OnceValue。把重试、超时和退避放在请求或缓存层；只有真正的一次性初始化才适合用 OnceValue。