init()在包加载时执行，无法按需延迟初始化，不支持传参和错误处理，易导致panic、调试困难、测试难mock及启动拖慢。
为什么直接用 init() 加载配置会出问题
因为 Go 的 init() 函数在包导入时就执行，此时应用可能还没准备好连接配置中心（比如 etcd、Nacos 或 Consul），甚至日志、网络客户端都未初始化。强行在这里拉取远程配置，容易 panic 或超时失败，且无法重试或监听变更。
用 sync.Once 延迟初始化配置客户端
把配置中心客户端（如 clientv3.New）和首次拉取逻辑封装进一个带 sync.Once 的函数里，确保只执行一次且线程安全。注意：不要在 Once.Do 里做阻塞重试——失败就该让调用方处理。
- 配置客户端实例必须是全局可访问的变量（如
var configClient *nacos.Client），不能藏在局部作用域 - 首次拉取失败时，建议返回明确错误（如
err != nil），而不是静默 fallback 到默认值——否则上线后配置不生效很难排查 - 如果用 viper，别直接
viper.AddRemoteProvider后就viper.ReadRemoteConfig()，它内部没做连接健康检查，容易卡住
配置变更必须走事件驱动，不是轮询
etcd 的 Watch、Nacos 的 Subscribe、Consul 的 Watch 都提供长连接+回调机制。轮询不仅增加服务端压力，还会放大延迟（比如 5s 间隔下，配置生效最大延迟就是 5s）。
- 回调函数里别做耗时操作（如写文件、发 HTTP 请求），应只更新内存中的
map[string]interface{}或触发 channel 通知 - 务必处理监听中断（如 etcd
watchChan.Err()不为 nil），自动重连；Nacos 的ListenConfig失败后需手动Subscribe恢复 - 变更通知和实际业务使用之间要有同步保护——用
sync.RWMutex读多写少场景比sync.Mutex更合适
如何安全地暴露动态配置给业务代码
避免让业务层直接调用 Get(key) 并自己类型断言。应该提供类型安全的访问接口，比如 GetInt64("timeout_ms") 或 GetStringSlice("whitelist")，内部统一处理空值、类型错误、key 不存在等情况。
- 所有配置访问都应有默认值兜底（如
GetInt64("timeout_ms", 3000)），但默认值不能硬编码在业务逻辑里，而要集中定义 - 不要把配置结构体指针直接返回给业务——一旦配置变更，原指针内容可能被并发修改，导致数据竞争
- 如果业务需要结构化配置（如
type DBConfig struct { Host string; Port int }），用json.Unmarshal从最新 raw data 构建新实例，而不是复用旧对象
最麻烦的其实是配置 schema 变更时的兼容性——比如旧版本还依赖已删除的 redis.password 字段，这时候光靠 default 值不够，得加运行时校验或迁移钩子。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
