viper.WatchConfig()仅触发回调，不自动热更新；必须在回调中显式调用viper.ReadInConfig()和viper.Unmarshal()，并原子替换配置指针，否则viper.Get()始终返回旧值。
配置热加载不是调用一个函数就能自动生效的事。viper.WatchConfig() 只注册监听并触发回调，不读文件、不解析、不更新内存里的配置值——漏掉 viper.ReadInConfig() 或 viper.Unmarshal()，viper.Get() 永远返回旧值。
为什么改了 YAML 文件，viper.Get() 还是旧值
根本原因是 viper.WatchConfig() 仅绑定 fsnotify 事件和你的回调函数，它不做任何解析动作。常见断点就卡在这三步：
- 回调里没调
viper.ReadInConfig()：文件内容根本没进 viper 内部 map - 没显式调
viper.Unmarshal(&cfg)：即使 ReadInConfig 成功，结构体字段仍是零值（viper 不 diff 字段，只刷新自己缓存） -
viper.SetConfigType("yaml")没在ReadInConfig()前设好：viper 默认按首次加载类型解析，类型不匹配会静默失败或 panic
热更新必须原子切换，不能直接赋值全局 struct
并发读配置时，cfg = newCfg 是危险操作：多个 goroutine 可能同时读到“半更新”状态（Port 已变但 DBURL 还是旧的），尤其结构体含指针或嵌套 map 时极易 panic。
- 推荐用
sync/atomic.Value存配置指针：globalConf.Store(&newCfg)，读取时globalConf.Load().(*Config)，无锁且线程安全 - 若用
sync.RWMutex，写操作必须Lock()，读操作必须RUnlock()；别混用Unlock()，否则崩溃 - 绝对不要在回调里直接改字段，如
cfg.Port = 8080—— 破坏结构体一致性，校验和替换就失去意义
容器/K8s 环境下 viper.WatchConfig() 静默失效
Linux 容器默认 inotify 句柄极低，常见报错是 No space left on device（不是磁盘满，是 inotify 耗尽）。检查命令：cat /proc/sys/fs/inotify/max_user_watches，宿主机和容器内都要一致。
使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。
- Docker 启动必须加参数：
--sysctl fs.inotify.max_user_watches=524288，只调高宿主机无效 - K8s 中 ConfigMap 挂载后不更新？先确认挂载点权限：
ls -l /etc/config/app.yaml，确保 Go 进程有读权限（某些镜像 umask 导致文件不可读） - 更稳妥做法：启用轮询模式，启动前设环境变量
VIPER_CONFIG_WATCH_POLL=true（v1.12+ 支持）
Consul Template 或 SIGHUP 触发热更新时的坑
consul-template 的 -exec 默认发 SIGHUP，但 Go 程序若没注册处理器，信号就被内核忽略，看起来“没反应”。
- 必须用
signal.Notify(sigChan, syscall.SIGHUP)捕获，且sigChan要带缓冲（至少 cap=1），否则信号丢失 -
-exec别写成sh -c "pkill && ./myapp"：shell 会吞掉信号；应直接写./myapp或用exec.Command - 收到 SIGHUP 后，不要 reload config.yaml 再覆盖全局变量——要走和文件监听一致的路径：
ReadInConfig()→ 校验 →Unmarshal()→ 原子替换
最容易被忽略的是错误处理粒度：配置语法错误、字段缺失、类型不匹配都可能 runtime 发生，一旦解析失败却强行替换，下游代码读 nil 字段或非法值会直接 panic。新配置必须先解析到临时变量，校验通过再切换，日志要明确到具体行号和字段。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
