viper.watchconfig()仅监听文件变更而不自动重载，必须在onconfigchange回调中依次调用readinconfig、unmarshal并原子替换全局配置，否则viper.get()仍返回旧值。
直接改配置文件不重启服务，viper.WatchConfig() 本身不会重载数据，必须手动触发解析并原子替换——否则所有 viper.Get() 都返回旧值。
为什么改了 config.yaml，viper.Get("port") 还是旧的
因为 viper.WatchConfig() 只注册 fsnotify 监听，仅在文件变更时发通知，**不读文件、不解析、不刷新内部缓存**。常见错误是只调用它，却没在回调里做三件事：
-
viper.ReadInConfig()：重新加载文件内容到 viper 内部 map -
viper.Unmarshal(&newCfg)：把新数据写入你的结构体（注意传指针） - 用
atomic.Value或sync.RWMutex安全替换全局配置指针，而非直接赋值字段
漏掉任意一步，业务代码拿到的都是“假更新”——日志显示已变更，但 http.Server.Addr 仍是旧端口。
viper.OnConfigChange() 回调里必须检查错误并设类型
回调函数运行在独立 goroutine，且 viper.ReadInConfig() 可能失败（比如 YAML 格式错、文件被锁、权限不足），不检查就静默跳过，后续 Unmarshal 会用旧缓存数据覆盖结构体，导致字段为零值。
还要确保 viper.SetConfigType("yaml") 在 viper.ReadInConfig() 之前调用，否则首次变更时 viper.Unmarshal() 报 Unsupported Config Type ""。路径也必须精确到文件：viper.SetConfigFile("./config.yaml")，不能写目录。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
嵌套结构体（如 slice/map）更新必须新建实例
viper.WatchConfig() 默认只刷新顶层键值，对 database.connections[0].timeout 这类嵌套字段不会自动同步。旧 map 或 slice 的底层数组可能被复用，造成字段残留、并发 panic 或逻辑错乱。
正确做法是每次更新都 new(Config) 创建全新结构体实例，并确保字段带正确 tag（如 yaml:"timeout"）。别试图原地修改字段，尤其当结构体含指针或 sync.Mutex 字段时——它们无法安全热更新。
配置变了，DB 连接池和 HTTP 客户端不会自动响应
viper 不管资源生命周期。改了 db.max_open_conns，不会自动调 sql.DB.SetMaxOpenConns()；改了 http.timeout，也不会让已有 http.Client 生效新值。
你得自己实现清理与重建逻辑：收到配置变更信号后，主动调用 db.Close()、db = newDB(cfg)、client.Timeout = cfg.HTTP.Timeout。最常被忽略的是定时器、缓存刷新周期、限流器这些依赖配置的组件——它们必须显式 reload 才能真正“动起来”。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
