配置热加载这事儿，很多开发者都以为调个函数就能自动生效，但实际情况往往没那么简单。viper.WatchConfig() 只注册监听并触发回调，它不读文件、不解析、不更新内存里的配置值——漏掉 ReadInConfig() 或 Unmarshal()，viper.Get() 永远返回旧值。这一点，不少人踩过坑。
为什么改了 YAML 文件，viper.Get() 还是旧值
根本原因在于，WatchConfig() 仅仅绑定 fsnotify 事件和你的回调函数，它不做任何解析动作。常见的断点通常卡在三步中的某一步：
- 回调里没调 ReadInConfig()：文件内容根本没进 viper 内部 map
- 没显式调 Unmarshal(&cfg)：即使 ReadInConfig 成功，结构体字段仍是零值（viper 不 diff 字段，只刷新自己缓存）
- SetConfigType("yaml") 没在 ReadInConfig() 前设好：viper 默认按首次加载类型解析，类型不匹配会静默失败或 panic
所以，别指望 WatchConfig() 能自动搞定一切，该写的步骤，一个都不能少。
热更新必须原子切换，不能直接赋值全局 struct
并发读配置时，直接写 cfg = newCfg 是极其危险的操作：多个 goroutine 可能同时读到“半更新”状态——Port 已变但 DBURL 还是旧的，尤其结构体含指针或嵌套 map 时极易 panic。
- 推荐用 sync/atomic.Value 存配置指针：globalConf.Store(&newCfg)，读取时 globalConf.Load().(*Config)，无锁且线程安全
- 若用 sync.RWMutex，写操作必须 Lock()，读操作必须 RUnlock()；别混用 Unlock()，否则直接崩溃
- 绝对不要在回调里直接改字段，比如 cfg.Port = 8080 —— 这破坏了结构体一致性，校验和替换就失去了意义
容器/K8s 环境下 WatchConfig() 静默失效
Linux 容器默认 inotify 句柄极低，常见报错是 No space left on device（不是磁盘满，是 inotify 耗尽）。检查命令：cat /proc/sys/fs/inotify/max_user_watches，宿主机和容器内都要一致。
- 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+ 支持）
Consul Template 或 SIGHUP 触发热更新时的坑
consul-template 的 -exec 默认发 SIGHUP，但 Go 程序若没注册处理器，信号就被内核忽略，看起来“没反应”。
- 必须用 signal.Notify(sigChan, syscall.SIGHUP) 捕获，且 sigChan 要带缓冲（至少 cap=1），否则信号丢失
- -exec 别写成 sh -c "pkill && ./myapp"：shell 会吞掉信号；应直接写 ./myapp 或用 exec.Command
- 收到 SIGHUP 后，不要 reload config.yaml 再覆盖全局变量——要走和文件监听一致的路径：ReadInConfig() → 校验 → Unmarshal() → 原子替换
最容易被忽略的是错误处理粒度：配置语法错误、字段缺失、类型不匹配都可能 runtime 发生，一旦解析失败却强行替换，下游代码读 nil 字段或非法值会直接 panic。新配置必须先解析到临时变量，校验通过再切换，日志要明确到具体行号和字段。
