Go配置延迟加载核心是首次使用时用sync.Once或sync.Lazy实现线程安全初始化，禁在init()中做I/O；因init()同步串行，失败即进程退出，且第三方库也可能隐式触发I/O。
Go 语言配置项延迟加载的核心是：别在 init() 或包级变量初始化时读文件、连远程、解析 YAML —— 这些操作必须挪到首次使用时，用 sync.Once 或 Go 1.21+ 的 sync.Lazy 控制执行时机和并发安全。
为什么 config 不能放 init() 里？
因为 init() 是同步、串行、不可中断的。一旦里面调了 viper.ReadInConfig()、os.ReadFile("config.yaml") 或 http.Get("https://cfg.example.com")，整个进程就卡住，失败直接退出，连日志都来不及打。
- 典型现象：
go run main.go很快，但go build && ./myapp启动要 3–6 秒；pprof 火焰图里热点全堆在runtime.doInit下 - 第三方库也常偷偷干这事：运行
go tool compile -S main.go | grep "CALL.*init"能快速揪出哪些依赖包在初始化阶段做了 I/O -
zap.NewProduction()放init()里就是个经典坑——它默认做 JSON 编码 + 时间格式化 + 调用栈捕获，本地调试请换zap.NewDevelopment()
用 sync.Once 实现线程安全的懒加载
sync.Once 是最轻量、最可控的方式，适合单例型配置对象（比如全局 *Config 结构体）。
关键点：
立即学习“go语言免费学习笔记（深入）”；
- 不要把
sync.Once.Do()写在init()里——那是冗余，init()本就是单次执行 -
Do()里不能含无 timeout 的阻塞调用：比如裸写db.Ping()或没设context.WithTimeout的http.Get()，否则所有并发首请求会排队等它完成 - 必须返回
error：别在Do()里log.Fatal()或panic，让上层决定降级或重试
示例：
type Config struct {
DatabaseURL string
RedisURL string
}
var (
config *Config
once sync.Once
)
func GetConfig() (*Config, error) {
once.Do(func() {
cfg := &Config{}
// 这里加 context.WithTimeout 和错误处理
if err := loadFromViper(cfg); err != nil {
// 记录错误，但不 panic
config = nil
return
}
config = cfg
})
if config == nil {
return nil, fmt.Errorf("failed to load config")
}
return config, nil
}
Go 1.21+ 推荐用 sync.Lazy[string]
如果你只延迟加载一个简单值（比如字符串、JSON 字节切片），sync.Lazy[T] 更简洁、值语义更清晰，且自动处理一次性初始化。
注意它和 sync.Once 的差异：
-
sync.Lazy是值类型，拷贝后仍共享初始化状态；sync.Once是指针类型，需显式管理生命周期 -
Lazy.Init()返回的是具体值，不是 error；若初始化失败，需在闭包内自行处理（比如返回零值 + 打日志） - 不适合复杂结构体或需要 error 传播的场景；更适合“读一次就固定”的配置片段，如
APIBaseURL、FeatureFlag开关
示例：
var apiBaseURL sync.Lazy[string]
func GetAPIBaseURL() string {
return apiBaseURL.Init(func() string {
url := os.Getenv("API_BASE_URL")
if url == "" {
log.Printf("API_BASE_URL not set, using default")
url = "https://api.example.com"
}
return url
})
}
结构体字段级延迟加载（模拟注解行为）
当配置项分散在多个结构体字段、且某些字段极少被访问时，可以结合结构体标签（struct tag）和方法封装实现字段级惰性初始化。
Go 本身不支持注解，但可用标签模拟逻辑标记：
- 定义字段带
lazy:"true"标签 - 提供
GetDatabaseURL()方法，在内部检查是否已初始化，未则触发加载 - 每个字段配独立的
sync.Once，避免一个字段失败影响其他字段
这种模式适合大配置结构体中部分字段依赖远程服务、证书文件等高成本资源的场景，但会增加代码复杂度，一般优先用前两种方式。
真正容易被忽略的点是：延迟加载不是“越晚越好”，而是“首次用时才做，且只做一次”；同时必须考虑失败后的可观测性和恢复路径——比如配置加载失败时，是返回默认值、panic、还是让 HTTP handler 返回 503？这个决策点不在 sync.Once 里，而在调用它的业务逻辑中。
