viper.watchconfig()仅监听文件变更并触发回调，不自动重读、解析或刷新缓存；必须在onconfigchange回调中依次调用viper.readinconfig()、viper.unmarshal(&cfg)，并用atomic.value原子替换配置指针，否则viper.get()始终返回旧值，且并发读写可能导致半更新状态或panic。
viper.WatchConfig() 不会自动更新配置值，必须在回调里显式调用 viper.ReadInConfig() 和 viper.Unmarshal()，否则 viper.Get() 永远返回旧值。
为什么改了 YAML 文件，viper.Get() 还是旧值
根本原因是 viper.WatchConfig() 只注册文件监听并触发回调，不读文件、不解析、不刷新内存缓存。常见漏掉的三步：
- 回调中没调
viper.ReadInConfig()：新内容根本没进 viper 内部 map - 没调
viper.Unmarshal(&cfg)：即使 ReadInConfig 成功，结构体字段仍是零值（viper 不 diff 字段，只刷新自己缓存） -
viper.SetConfigType("yaml")没在ReadInConfig()前设好：viper 默认按首次加载类型解析，类型不匹配会静默失败或 panic
如何安全地原子替换全局配置指针
直接赋值 cfg = newCfg 是危险操作：并发读时可能拿到“半更新”状态（Port 已变但 DBURL 还是旧的），尤其结构体含指针或嵌套 map 时极易 panic。
- 用
atomic.Value存储配置指针，写入前先校验新配置合法性（如端口范围、URL 格式） - 写入逻辑：构造完整
*Config→ 校验通过 →globalConf.Store(newConf) - 读取逻辑：在 HTTP handler 中用
conf := globalConf.Load().(*Config)，无锁、无竞态、无拷贝 - 不要用
sync.RWMutex包裹大结构体——读多写少场景下，锁竞争会成为瓶颈
容器/K8s 环境下 viper.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+ 支持）
收到 SIGHUP 或 USR2 后，怎么避免配置热更新变成“热崩溃”
Consul Template、supervisor 或手动 kill -SIGHUP 触发时，若处理不当，会因错误传播导致服务中断。
- 必须用
signal.Notify(sigChan, syscall.SIGHUP)捕获信号，且sigChan要带缓冲（至少 cap=1），否则信号丢失 - 收到信号后，不要直接 reload config.yaml 再覆盖全局变量——要走和文件监听一致的路径：
ReadInConfig()→ 校验 →Unmarshal()→ 原子替换 - 错误处理粒度要细：配置语法错误、字段缺失、类型不匹配都可能引发 panic；失败时不替换配置，打 error 日志，保留旧配置继续服务
- 别在回调里做耗时操作（如远程拉证书、HTTP 请求），否则阻塞 fsnotify goroutine，后续变更事件被丢弃
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
