Viper 默认不热更新配置文件，因其仅初始化时加载一次文件到内存，后续操作均读取缓存，不重新读磁盘；需手动用 fsnotify 监听文件变化并调用 WatchConfig() 或 ReadInConfig() 实现热更新。
为什么 Viper 默认不热更新配置文件
Viper 本身是配置读取器，不是监听器。它初始化时加载一次文件，后续调用 Get 或 Unmarshal 都只是查内存缓存，不会重新读磁盘 —— 所以改了文件，程序完全感知不到。
热更新必须手动加监听逻辑，常见做法是用 fsnotify 监控文件变化，再触发 Viper.ReadInConfig() 或 Viper.WatchConfig()。
-
Viper.WatchConfig()是封装好的快捷方式，但只支持OnConfigChange回调，不返回错误，出问题难排查 - 它默认监听整个配置文件路径，如果用
SetConfigFile指定了具体文件（比如config.yaml），就只监听那个文件；如果用SetConfigName+AddConfigPath，则监听路径下所有匹配的文件（可能误触） - 监听启动前必须先成功调用过
ReadInConfig()，否则WatchConfig()会 panic：”no config file found“
Viper.WatchConfig() 的正确初始化顺序
顺序错一步，监听就静默失效。最简可靠写法：
v := viper.New()
v.SetConfigName("config")
v.AddConfigPath("./conf")
v.SetConfigType("yaml")
// 必须先成功读一次
if err := v.ReadInConfig(); err != nil {
log.Fatal(err)
}
// 再开启监听
v.WatchConfig()
v.OnConfigChange(func(e fsnotify.Event) {
log.Println("Config file changed:", e.Name)
})
- 别在
WatchConfig()后才调ReadInConfig()—— 这会导致监听没绑定到任何已加载配置 -
OnConfigChange回调里不能直接调v.Get，因为此时新内容还没重载进内存；要等回调返回后，Viper内部才自动调ReadInConfig() - 如果配置解析失败（比如 YAML 格式错），
Viper会跳过更新，但不会报错，日志里也看不到提示 —— 建议在OnConfigChange里手动再调一次v.ReadInConfig()并检查 error
热更新后结构体字段没刷新？注意 Unmarshal 的时机
很多人把配置反序列化成结构体后就不管了，以为监听一触发，结构体字段会自动更新。其实不会 —— Viper 只更新自己内部的 map，你原来的结构体还是旧值。
立即学习“go语言免费学习笔记（深入）”；
- 必须在
OnConfigChange回调里或之后，重新调v.Unmarshal(&cfg)，才能把新配置刷进结构体 - 如果结构体字段用了指针或嵌套 map/slice，
Unmarshal会替换整个值，不是 merge；原有引用可能失效 - 并发访问该结构体时，要加锁或用原子替换（比如用
atomic.Value存结构体指针），否则可能读到半新半旧状态
Linux 下修改文件却没触发通知？检查 fsnotify 的底层限制
fsnotify 依赖 inotify，而 inotify 对每个进程有监听数量和内存上限。常见静默失效场景：
- 编辑器（如 VS Code、vim）保存时可能先写临时文件再 rename，inotify 默认只监听 rename 事件，但
Viper.WatchConfig()默认只注册了fsnotify.Write和fsnotify.Create，漏了fsnotify.Rename—— 解决办法是手动用fsnotify监听全事件，再调v.ReadInConfig() - docker 容器内挂载 host 文件时，inotify 事件可能不穿透（尤其 macOS 上的 Docker Desktop），建议改用轮询（
time.Ticker+os.Stat比较 ModTime）作为 fallback - Linux 系统级 inotify 限制可通过
/proc/sys/fs/inotify/max_user_watches查看，小项目设到 512k 通常够用
热更新看着简单，真正稳定跑在线上，得同时扛住编辑器行为、容器环境、并发读写和解析失败这四层干扰。少踩一个，就可能半夜收告警。
