viper.WatchConfig()仅触发回调，不自动重读配置；必须在回调中显式调用ReadInConfig()和Unmarshal()并原子替换配置指针，否则viper.Get()始终返回旧值。
viper.WatchConfig() 回调里不调 ReadInConfig 就等于没更新
改完 config.yaml，日志打印“配置已更新”，但 viper.GetInt("port") 还是旧值——这是最常见现象。根本原因： viper.WatchConfig() 只注册 fsnotify 监听并触发回调，**不读文件、不解析、不刷新内部缓存**。必须在回调第一行显式调用 viper.ReadInConfig()，否则 viper.Get() 读的仍是上次加载进内存的老数据。
还要注意：viper.SetConfigType("yaml") 必须在 viper.ReadInConfig() 之前设置，否则类型不匹配会静默失败或 panic；若首次加载用的是 JSON，后续 Watch 时却写 YAML，也会出错。
- 回调开头必须加错误检查：
if err := viper.ReadInConfig(); err != nil { log.Printf("reload failed: %v", err); return } - 紧接着要
viper.Unmarshal(&newCfg)，否则结构体字段仍为零值（viper.Unmarshal()不 diff，只把当前缓存值写入目标指针） - 别依赖
viper.Get("db.host")实时反映变更：它读的是 viper 自己的 map 缓存，而该缓存仅在ReadInConfig()后刷新
并发读配置时直接赋值 cfg = newCfg 是危险操作
多个 goroutine 同时执行 http.HandleFunc 或定时任务，如果热更新时直接写 cfg.Port = 8080 或 globalCfg = &newCfg，可能读到“半更新”状态：Port 已变，但 cfg.DBURL 还是旧的，尤其当结构体含嵌套 map 或指针字段时，极易 panic。
正确做法是原子切换配置指针。推荐用 sync/atomic.Value：
- 声明全局变量：
var globalConf atomic.Value - 初始化时存默认配置指针：
globalConf.Store(&defaultCfg) - 热更新成功后：
globalConf.Store(newCfg)（newCfg是新解析的*Config） - 业务代码固定写法：
conf := globalConf.Load().(*Config)，类型断言不能省，且建议判空
若坚持用 sync.RWMutex，写操作必须 mu.Lock() → cfg = newCfg → mu.Unlock()，读操作必须 mu.RLock() → defer mu.RUnlock()，漏掉 defer 就可能死锁。
容器/K8s 下 viper.WatchConfig() 静默失效的三大原因
现象是“改了文件没反应”，控制台无报错，排查方向很明确：
-
inotify 句柄耗尽：Linux 容器默认
/proc/sys/fs/inotify/max_user_watches极低（常为 8192），No space left on device并非磁盘满，而是 inotify 耗尽。Docker 启动必须加--sysctl fs.inotify.max_user_watches=524288，只调高宿主机无效 -
监听路径不匹配：必须监听**具体文件路径**，如
watcher.Add("./conf/app.yaml")；只加目录"./conf"在 macOS 下可能漏事件，且编辑器保存常先写临时文件再 rename，触发的是 rename 事件而非 write -
ConfigMap 挂载权限问题：K8s 中挂载的
/etc/config/app.yaml可能因镜像 umask 导致不可读，用ls -l /etc/config/app.yaml确认 Go 进程有读权限
更稳妥的做法是启用轮询模式：启动前设环境变量 VIPER_CONFIG_WATCH_POLL=true（v1.12+ 支持），绕过 inotify 限制。
收到 SIGHUP 或远程通知时别跳过校验和原子替换
Consul Template、systemd 或自定义 HTTP 端点触发更新时，容易犯的错是：收到信号就直接 viper.ReadInConfig() → 覆盖全局变量，跳过校验和安全替换。
必须走和文件监听一致的路径：
- 先捕获信号：
signal.Notify(sigChan, syscall.SIGHUP)，且sigChan要带缓冲（至少 cap=1），否则信号丢失 - 收到后，仍需
viper.ReadInConfig()→ 校验语法/字段/类型 →viper.Unmarshal(&newCfg)→ 原子替换指针 - 切勿在信号 handler 中做耗时操作（如网络请求、大文件读取），应转发给 worker goroutine 处理
最容易被忽略的是错误粒度：配置语法错误、字段缺失、端口超出范围等，都应在 Unmarshal() 后立刻拦截，失败时不替换，继续用旧配置——宁可不变也不出错。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
