viper.watchconfig()仅注册监听不自动重载，必须阻塞主线程、在回调中显式调用readinconfig和unmarshal，并用atomic.value原子替换配置指针，否则仍返回旧值。
Go 语言没有运行时代码重载能力，所谓“热更新”在生产环境里几乎全是配置热替换或进程级重载；真要动函数体，不是靠 plugin 就是硬上内存 patch——这两条路在实际项目中基本等于自毁。
为什么 viper.WatchConfig() 单独调用就失效
它只注册监听器，不阻塞主线程，也不自动重读。调完 viper.WatchConfig() 后如果 main() 立即返回，整个进程就退出了，监听根本没机会触发。
- 必须确保程序长期存活：启动 HTTP server（
http.ListenAndServe()）、或加select {}（仅调试） -
viper.AddConfigPath()和viper.SetConfigName()必须在WatchConfig()前完成，否则回调里viper.ReadInConfig()会报Config File Not Found -
OnConfigChange回调里不做viper.ReadInConfig()，配置缓存永远不变；不做viper.Unmarshal()，结构体字段也不会更新
fsnotify + atomic.Value 是最轻量可靠的组合
比起依赖 viper 的封装，自己用 fsnotify 监听 + atomic.Value 替换指针，控制粒度更细、失败路径更清晰、无隐式状态。
- 监听事件类型只关注
fsnotify.Write和fsnotify.Chmod，覆盖 Vim/VS Code 等编辑器保存行为 - 每次成功解析后才调用
globalConf.Store(&newCfg)，加载失败直接跳过，旧配置继续生效 -
Config结构体必须全字段导出、不含sync.Mutex或闭包等不可复制字段，否则unsafe.Pointer转换会崩溃 - 业务代码统一通过
conf := globalConf.Load().(*Config)读取，禁止缓存该指针——对象可能被下一次更新回收
容器环境里 inotify 资源耗尽是静默失败
不是配置没变，而是 fsnotify 根本收不到事件。Docker 默认的 inotify.max_user_watches 通常只有 8192，一个服务监听几十个配置文件就容易打满。
- 宿主机查限制：
cat /proc/sys/fs/inotify/max_user_watches - Docker 启动时加参数：
--sysctl fs.inotify.max_user_watches=524288 - Kubernetes 中通过
securityContext.sysctls设置，或改用轮询兜底（仅限低频场景） - 监听路径必须是配置文件的**绝对路径**，不能监听整个目录——否则子目录变更也会误触发
真正难的从来不是“怎么让配置变”，而是“怎么确保所有 goroutine 在任意时刻读到的都是完整、合法、一致的状态”。原子指针替换只是手段，背后是对数据生命周期和并发访问边界的清醒判断。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
