viper.WatchConfig()仅监听文件变更，不自动重载配置；必须在viper.OnConfigChange()回调中依次调用viper.ReadInConfig()刷新缓存、viper.Unmarshal()更新结构体，并用atomic.Value原子替换指针，否则viper.Get()始终返回旧值。
viper.WatchConfig() 本身不重载配置，只监听文件变化；必须配合 viper.OnConfigChange() 回调并显式调用 viper.ReadInConfig() 和 viper.Unmarshal()，否则改了文件也拿不到新值。
为什么改了 config.yaml，viper.Get("port") 还是旧的？
根本原因是 viper.WatchConfig() 只启动 fsnotify 监听，不读文件、不解析、不刷新内部缓存。它就像装了个门铃，但没人去开门——回调函数就是那个“开门人”，而 viper.ReadInConfig() 是开门动作。
- 没在回调里调
viper.ReadInConfig()→ 缓存仍是旧数据 →viper.Get()必然返回旧值 -
viper.SetConfigType("yaml")必须在viper.ReadInConfig()之前设置，否则类型不匹配会静默失败（尤其首次加载是 JSON、Watch 时却改 YAML） - 回调中漏掉错误检查：
if err := viper.ReadInConfig(); err != nil { log.Printf("reload failed: %v", err); return }→ 一次 YAML 格式错误就会卡死后续所有监听
如何安全替换运行时配置结构体？
直接赋值 globalCfg = &newCfg 或逐字段写 cfg.Port = newPort 是危险的：多个 goroutine 并发读时可能看到“半更新”状态（Port 已变，DB.Addr 还是旧的），尤其含嵌套 map 或指针字段时极易 panic。
Pandas 配置文件报告生成器
下载
使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。
- 推荐用
sync/atomic.Value：声明var globalConf atomic.Value，初始化存默认指针，热更新成功后globalConf.Store(&newCfg)，业务代码统一用conf := globalConf.Load().(*Config) - 若坚持用
sync.RWMutex，必须确保所有读路径都走mu.RLock() / defer mu.RUnlock()，所有写路径走mu.Lock() / defer mu.Unlock()；漏defer就可能死锁 - 别在回调里做耗时操作（如 HTTP 请求、DB 查询），否则阻塞
fsnotify事件队列，导致后续变更堆积或丢失
GoLand 项目里 viper.WatchConfig() 静默失效的常见原因
本地开发用 GoLand 跑服务时，“改了配置没反应”往往不是代码问题，而是环境限制：
-
inotify 句柄耗尽：Linux 容器或 WSL 默认
/proc/sys/fs/inotify/max_user_watches常为 8192，改配置触发事件时提示No space left on device却不是磁盘满——Docker 启动需加--sysctl fs.inotify.max_user_watches=524288，WSL2 则要在/etc/wsl.conf中配置 -
编辑器临时文件干扰：VS Code / GoLand 保存时先写
config.yaml~或.config.yaml.swp，触发无效Create事件；应在回调中严格过滤：filepath.Base(event.Name) == "config.yaml"，且只响应fsnotify.Write和fsnotify.Rename -
监听路径不精准：用
viper.AddConfigPath("./configs")但未指定viper.SetConfigFile("app.yaml")，viper.WatchConfig()只监听最终被viper.ReadInConfig()加载的那个文件，对目录下其他文件无感知
真正容易被忽略的是：业务代码是否还在启动时缓存了原始配置值。比如 timeout := viper.GetInt("http.timeout") 写在 main() 开头，后续永远用这个局部变量——热更新再完美也影响不到它。必须把配置读取下沉到每次使用前，或封装成带锁/原子读取的 GetConfig() 函数。
