viper.watchconfig()仅触发回调，不自动重载配置；必须在回调中手动调用readinconfig()和unmarshal()并原子替换结构体指针，否则viper.get()始终返回旧值。
viper.WatchConfig() 本身不重载配置，只发通知；必须在回调里手动 ReadInConfig + Unmarshal，否则 viper.Get() 永远返回旧值。
为什么改了 YAML 文件，viper.Get() 还是旧值
根本原因是 viper.WatchConfig() 只注册 fsnotify 监听并触发 OnConfigChange 回调，它不做三件事：不读文件、不解析内容、不更新你自己的结构体字段。
- 漏掉
viper.ReadInConfig()：新内容压根没进 viper 内部缓存 map - 漏掉
viper.Unmarshal(&cfg)：即使ReadInConfig()成功，你的cfg结构体仍是零值（viper 不 diff 字段，只刷新自己缓存） -
viper.SetConfigType("yaml")没在ReadInConfig()前设好：viper 默认按首次加载类型解析，类型不匹配会静默失败或 panic - 路径不一致：
viper.SetConfigFile("./config.yaml")和实际监听路径不匹配，ReadInConfig()可能读错文件甚至报ConfigFileNotFoundError
viper.WatchConfig() 没反应的常见原因
监听“启动了但没触发”，多数不是代码写错，而是运行时环境卡住。
- 主线程没阻塞：调完
viper.WatchConfig()后程序立刻退出，goroutine 来不及收事件。必须加select {}或启动 HTTP server 等长期逻辑 - inotify 句柄耗尽：Linux 容器默认
fs.inotify.max_user_watches极低（常为 8192），fsnotify会静默失败，报错类似No space left on device。需宿主机和容器都调高，Docker 启动时加--sysctl fs.inotify.max_user_watches=524288 - 挂载卷监听失效：Docker 用
-v ./config.yaml:/app/config.yaml时，容器内 overlayfs 层无法被 fsnotify 穿透。应把配置 COPY 进镜像，或改用轮询模式（设环境变量VIPER_CONFIG_WATCH_POLL=true） - 监听了目录而非文件：
viper.WatchConfig()默认监听配置文件所在目录，若该目录下有编辑器临时文件、日志等，会刷屏无关事件，甚至压垮监听器。建议只对单个明确路径生效，必要时自己用fsnotify.Watcher管理
如何安全地原子替换运行时配置
直接赋值 cfg = newCfg 是危险操作——并发读时可能拿到 Port 已变但 DBURL 还是旧的“半更新”状态，尤其结构体含指针或嵌套 map 时极易 panic。
- 用
sync/atomic.Value存储配置指针：globalConf.Store(newConf)，写入前先校验新配置合法性（如端口范围、URL 格式） - 读取统一走
globalConf.Load().(*Config)，无锁、无竞态、无拷贝 - 别在回调里直接改字段（如
cfg.Port = 8080），破坏结构体一致性 - 若需加锁，用
sync.RWMutex：写操作Lock()，读操作RUnlock()，别混用Unlock() - 热更新失败时必须保留旧配置快照，并记录完整错误（含文件路径、原始内容片段），不能静默忽略
真正容易被忽略的是：配置变更后，业务逻辑是否真用了新值？比如数据库连接池没重建、HTTP client timeout 没重设、日志级别没同步——这些得在 OnConfigChange 回调里显式处理，viper 一概不管。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
