Go语言配置热加载需三步缺一不可：用fsnotify监听具体文件路径、viper.WatchConfig()注册回调并显式调用ReadInConfig()和Unmarshal()刷新、用atomic.Value或sync.RWMutex原子切换配置指针，否则viper.Get()和结构体字段始终为旧值。
Go 语言本身不提供配置热加载能力，必须自己组合 fsnotify 监听 + 配置解析 + 原子切换三步，缺一不可；只调 viper.WatchConfig() 或只起个 goroutine 轮询 os.Stat，都会导致“改了文件但没生效”。
为什么 fsnotify.Add() 必须传具体文件路径，不能只加目录
macOS 下监听目录（如 "./config"）可能漏掉事件，尤其编辑器保存时先写临时文件再 rename，触发的是 fsnotify.Create + fsnotify.Remove，而非 fsnotify.Write；而监听单个文件路径（如 "./config/app.yaml"）能稳定捕获最终的替换动作。
- 监听前务必用
os.Stat确认文件存在，否则watcher.Add()失败会被静默吞掉 - 若需监听多个配置文件，不要反复
Add，而是统一监听父目录，再在事件中用filepath.Base(e.Name)过滤出"app.yaml"、"db.yaml"等目标文件 - Linux 容器中常见
No space left on device错误，实际是/proc/sys/fs/inotify/max_user_watches耗尽，需启动容器时加--sysctl fs.inotify.max_user_watches=524288
viper.OnConfigChange 回调里必须手动调用 ReadInConfig 和 Unmarshal
viper.WatchConfig() 只发通知，不读文件、不解析、不更新任何变量；回调里漏掉 viper.ReadInConfig()，viper.Get() 就永远返回旧值；漏掉 viper.Unmarshal(&cfg)，你声明的结构体字段就一直是零值。
使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。
- 回调第一行必须是
if err := viper.ReadInConfig(); err != nil { log.Printf("reload failed: %v", err); return } - 紧接着要
if err := viper.Unmarshal(&newCfg); err != nil { /* 记录错误，跳过替换 */ }，不能直接赋值字段（如cfg.Port = viper.GetInt("port")），否则嵌套结构、默认值、类型校验全丢失 -
viper.SetConfigType("yaml")必须在viper.ReadInConfig()之前调用，否则类型不匹配会静默失败
配置结构体指针必须用 atomic.Value 或 sync.RWMutex 原子替换
直接写 cfg = newCfg 是非原子操作：结构体字段多时，某个 goroutine 可能读到 Port 已更新但 DBURL 还是旧的中间态；含 map/slice/指针字段时极易 panic。
立即学习“go语言免费学习笔记（深入）”；
- 推荐
atomic.Value：声明var globalConf atomic.Value，初始化时globalConf.Store(&defaultCfg)，热更新成功后globalConf.Store(&newCfg) - 业务代码读取固定写法：
conf := globalConf.Load().(*Config)，类型断言不能省，且Load()后建议判空 - 若需配合初始化逻辑（如 DB 连接池重建），
sync.Once必须包裹在原子替换之后，避免并发执行多次
真正难的不是监听到文件变化，而是确保下游所有组件——HTTP handler、DB client、logger level——都基于新配置运行；很多人 reload 成功却没效果，问题往往卡在没找到那个真正消费配置的模块入口点，比如忘了调 db.SetMaxOpenConns() 或 zap.AtomicLevel.SetLevel()。
