viper.WatchConfig()仅触发回调，不自动更新配置；必须在回调中手动调用ReadInConfig()和Unmarshal()才能刷新值，否则Get()始终返回旧值。
viper.WatchConfig() 本身不热更新配置，只触发回调；漏掉 viper.ReadInConfig() 或 viper.Unmarshal()，viper.Get() 永远返回旧值。
WatchConfig 回调里必须手动重读和反序列化
监听到文件变更后，viper 不会自动刷新内部缓存或结构体字段——它只调你的回调函数。常见错误是只打印日志就结束，没真正加载新内容。
- 回调第一行必须是
if err := viper.ReadInConfig(); err != nil { /* 记录并跳过 */ }：否则 viper 内部map[string]interface{}还是旧的 - 紧接着必须调
if err := viper.Unmarshal(&newCfg); err != nil { /* 记录并跳过替换 */ }：viper.Unmarshal()才把新解析的值写进 Go 结构体，不调它，cfg.Port就永远卡在初始值 -
viper.SetConfigType("yaml")必须在ReadInConfig()前设置好，否则类型不匹配会静默失败或 panic（比如文件是 YAML，但 viper 默认按 JSON 解析） - 别在回调里手动赋值字段（如
cfg.Port = viper.GetInt("port")）：嵌套结构、默认值、mapstructuretag 全部失效
热更新必须原子切换，不能直接赋值全局 struct
并发场景下，多个 goroutine 同时读配置时，直接写 cfg = newCfg 或逐字段修改，会导致读取时结构体处于“半更新”状态——Port 已变但 DBURL 还是旧的，尤其含指针或嵌套 map 时极易 panic。
- 推荐用
sync/atomic.Value存储指针：var globalConf atomic.Value，初始化时globalConf.Store(&defaultCfg) - 热更新成功后，必须
globalConf.Store(&newCfg)（注意是取地址，不是值） - 业务代码统一用
conf := globalConf.Load().(*Config)读取，类型断言不能省 - 避免用
sync.RWMutex包裹整个配置读写：读多写少时，锁竞争比原子操作更重
容器/K8s 环境下 WatchConfig 静默失效的根因和解法
Linux 容器默认 inotify 句柄极低（常为 8192），fsnotify 监听失败时只报 No space left on device，不是磁盘满，而是内核资源耗尽。
立即学习“go语言免费学习笔记（深入）”；
- Docker 启动必须加参数：
--sysctl fs.inotify.max_user_watches=524288；只调高宿主机无效，容器内也要一致 - K8s 中 ConfigMap 挂载后不更新？先检查挂载点权限：
ls -l /etc/config/app.yaml，确保 Go 进程有读权限（某些镜像 umask 导致文件不可读） - 更稳妥做法：启用轮询模式，启动前设环境变量
VIPER_CONFIG_WATCH_POLL=true（v1.12+ 支持） - 别监听整个目录（如
./conf），只对具体文件路径调用watcher.Add("./conf/app.yaml")，否则编辑器临时文件（.swp、.tmp）会干扰
主线程退出导致监听完全不触发
这是最隐蔽也最常踩的坑：调了 viper.WatchConfig()，但 main() 函数立刻 return，整个进程退出，监听器根本没机会运行。
- 必须确保程序长期运行，例如启动 HTTP server：
http.ListenAndServe(":8080", nil) - 调试时可用
select {}阻塞，但别上生产 -
viper.WatchConfig()必须在viper.ReadInConfig()成功之后调用，否则回调里ReadInConfig()会报Config File Not Found - 监听路径必须和实际加载路径一致：如果用
viper.SetConfigFile("/app/config.yaml")，但WatchConfig()默认监听工作目录，就会收不到事件
真正难的不是写几行监听代码，而是每次变更后都得走完整链路：校验语法 → 重读 → 反序列化 → 原子替换 → 错误兜底。少一步，线上就可能读到非法端口或空数据库连接串。
