热加载需完整实现监听、重读、校验、原子替换与线程安全；仅调用 viper.watchconfig() 不足，须阻塞主线程、前置配置路径设置、回调中手动 readinconfig 和 unmarshal、用 atomic.value 原子更新、容器内注意 inotify 限制或启用轮询。
热加载不是调用 viper.WatchConfig() 就完事了，它只负责监听文件系统事件，不自动重读、不校验、不替换、不线程安全——漏掉任一环节，配置就“看起来没更新”。
WatchConfig() 后程序立刻退出？主线程没阻塞
这是最常见失效原因：调用了 viper.WatchConfig()，但 main 函数随后就 return 了，整个进程退出，监听器根本没机会触发。
- 必须确保程序长期运行，比如启动 HTTP server：
http.ListenAndServe(":8080", nil) - 或手动阻塞：
select {}（仅调试用，别上生产） - 检查当前工作目录是否真有配置文件——
viper.AddConfigPath("./conf")和viper.SetConfigName("config")必须在WatchConfig()前完成，否则回调里viper.ReadInConfig()会报 “Config File Not Found”
OnConfigChange 回调里改了配置，handler 还读到旧值？没手动重解析
viper.WatchConfig() 触发回调时，Viper 内部缓存仍是旧内容；它不会自动调用 ReadInConfig() 或 Unmarshal()。
- 回调里第一件事必须是：
if err := viper.ReadInConfig(); err != nil { log.Printf("reload failed: %v", err); return } - 紧接着要重新绑定结构体：
if err := viper.Unmarshal(&newCfg); err != nil { /* 记录错误并跳过替换 */ } - 别依赖
viper.Get("db.host")实时返回新值——它读的是缓存 map，而 map 只在ReadInConfig()后才刷新
并发读写 panic 或读到中间态？全局变量直接赋值太危险
直接写 cfg = newCfg 或修改字段如 cfg.Port = newPort，在多 goroutine 场景下会导致读取时结构体部分字段已更新、部分未更新。
- 推荐用
atomic.Value存储指针：var globalConf atomic.Value，初始化时globalConf.Store(&defaultCfg) - 热更新成功后：
globalConf.Store(&newCfg)（注意是取地址） - 业务代码读取时固定写法：
conf := globalConf.Load().(*Config)，类型断言不能省 - 避免用
sync.RWMutex包裹整个配置读写——读多写少时，锁竞争反而比原子操作更重
容器里监听失效、Linux 报 “no space left on device”？inotify 资源耗尽
这不是磁盘满了，而是内核 inotify watch 数超限，尤其 Docker 默认限制极低（通常 8192），fsnotify 直接静默失败。
- 宿主机检查：
cat /proc/sys/fs/inotify/max_user_watches - 临时提高：
sudo sysctl -w fs.inotify.max_user_watches=524288 - Docker 运行时必须显式传参：
docker run --sysctl fs.inotify.max_user_watches=524288 ...，只调高宿主机无效 - 容器内稳定替代方案：设环境变量
VIPER_CONFIG_WATCH_POLL=true（Viper v1.12+），启用 5 秒轮询模式
真正难的不是监听文件变化，而是保证每次更新都经过校验、原子切换、错误兜底——尤其是配置含数据库连接池、HTTP client timeout 等有状态组件时，光换配置不够，还得通知对应模块重建资源。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
