sync.Once必须包裹整个配置加载链路，不能只包结构体创建；常见错误是仅用once.Do(&Config{})后在外调LoadFromFile，导致并发重复读文件、解析YAML或建数据库连接；正确做法是将os.ReadFile、viper.Unmarshal、校验等全部I/O和逻辑塞入闭包，并用包级initErr和instance协同处理错误与状态。
sync.Once必须包裹整个配置加载链路，不能只包结构体创建
常见错误是把 sync.Once.Do 仅用于 &Config{}，然后在外面调 c.LoadFromFile() 或 viper.Unmarshal()。结果是多个 goroutine 并发触发文件读取、YAML 解析、甚至重复建立数据库连接。
正确做法是把所有 I/O 和校验逻辑塞进闭包里：
-
os.ReadFile必须在once.Do内部执行 -
viper.Unmarshal或自定义解析逻辑也必须在里面 - 字段校验（如
c.validate()）不能漏掉，失败要设包级initErr - 最终成功才赋值给包级
instance，否则保持为nil
GetConfig() 必须检查初始化错误，不能直接返回指针
如果 sync.Once 闭包里初始化失败（比如文件不存在、YAML 格式错），instance 仍是 nil，但后续调用 GetConfig() 若直接返回它，上层会 panic。
所以 GetConfig() 要显式检查状态：
立即学习“go语言免费学习笔记（深入）”；
- 先判断包级
initErr != nil，直接返回该 error - 再判断
instance == nil（说明once.Do已执行但中途失败） - 不建议在
GetConfig()里重试或重新初始化——sync.Once不允许二次执行 - 错误日志应包含具体失败点，比如 “failed to parse config.yaml: yaml: line 5: did not find expected key”
配置结构体含 map/slice 时，禁止外部直接修改字段
sync.Once 只保初始化安全，不保运行时读写安全。若 Config 定义了 Hosts []string 或 Options map[string]string，多个 goroutine 同时调 append(c.Hosts, "x") 会触发 fatal error: concurrent map writes。
应对方式很实际：
- 初始化完成后，绝不要导出可写字段；把结构体字段全设为小写（未导出）
- 提供只读访问方法，如
c.GetHosts() []string，内部返回副本（append([]string{}, c.hosts...)） - 需要热更新？用
atomic.Value存储指针，reload()时config.Store(&newConfig)，而不是逐字段改旧实例 - 别图省事在
GetConfig()返回后让调用方直接改字段——这等于放弃封装
不要在 init() 或包级变量初始化中加载配置文件
包级变量写成 var Config = loadConfig() 或在 init() 里调 os.ReadFile，看似简洁，实则埋雷：
-
init()无法返回 error，失败只能panic，导致整个服务启动失败且无上下文 - 配置路径或环境变量（如
os.Getenv("ENV")）在init()阶段可能还未被flag.Parse()或os.Setenv()设置 - 单元测试时无法替换配置源，因为
init()在测试函数运行前已执行完毕 - 文件读取失败后无法重试，也无法注入 mock 数据
真正可控的时机是 main() 开头：先解析 flag/环境变量，再显式调一次 InitConfig()（内部用 sync.Once），之后所有 GetConfig() 才可用。
