viper.watchconfig() 仅触发回调通知，不自动重读配置；必须在回调中显式调用 viper.readinconfig() 和 viper.unmarshal() 并原子替换配置，否则仍返回旧值。
用 viper.WatchConfig() 前必须手动调用 viper.ReadInConfig()
很多人以为只要开了 viper.WatchConfig()，配置文件一改，viper.Get() 就自动返回新值——这是错的。它只发通知，不自动重读。你注册的回调里如果没显式调用 viper.ReadInConfig() 和 viper.Unmarshal()，业务代码拿到的还是旧配置。
- 监听生效但值不变：现象是日志打印“配置已更新”，但
viper.GetInt("port")仍返回旧端口 - 正确流程是：
viper.ReadInConfig()→ 校验 →viper.Unmarshal(&newCfg)→ 安全替换（如atomic.StorePointer()） - 别在回调里直接赋值全局结构体字段，否则并发读写会 panic；要用指针原子替换或
sync.RWMutex - Windows 下若配置文件被编辑器锁住（如 VS Code 临时写入），
fsnotify可能收不到WriteEvent，建议监听CreateEvent并过滤*~、.swp等临时文件
用 atomic.Value 替换配置指针比加锁更稳
当配置结构体较大、HTTP handler 频繁读取时，sync.RWMutex 的读锁开销会明显上升。atomic.Value 提供无锁读取，只要保证写入的是合法指针，就天然线程安全。
-
atomic.Value只支持interface{}，所以得存*Config而不是Config；存值前务必校验（比如端口 > 0、URL 可解析） - 读取时写法固定：
conf := globalConf.Load().(*Config)，不能省略类型断言 - 不要在回调里做耗时操作（如重连 DB），应发 channel 或 signal 到主 goroutine 处理，避免阻塞 fsnotify 监听循环
- 注意：Go 1.24+ 对
unsafe.Pointer转换更严格，用atomic.StorePointer需配合unsafe包，而atomic.Value更推荐且无需 unsafe
Consul Template 触发热更新，Go 程序得接住 SIGHUP
consul-template 的 -exec 不是重启进程，而是发信号——默认是 SIGHUP。如果你的 Go 程序没注册处理器，信号就被内核忽略，看起来“热更新没反应”。
- 必须用
signal.Notify(sigChan, syscall.SIGHUP)捕获，且sigChan是带缓冲的 channel（至少 cap=1），否则信号可能丢失 -
-exec命令别写成sh -c "pkill ... && ./myapp"，shell 会吞掉信号；应直接写./myapp或用exec.Command - 收到
SIGHUP后，不要 reload config.yaml 再覆盖全局变量——要走和文件监听一致的路径：校验 → 新建实例 → 原子替换 - 本地调试时关掉
consul-template的健康检查（加-disable-health-checks），否则改一次配置要等 30 秒才触发
K8s ConfigMap 挂载后不更新？先查 inotify 和文件权限
Kubernetes 把 ConfigMap 挂成 volume 后，理论上文件内容变更会通过 inotify 通知进程。但实际常因挂载方式或容器权限导致 viper.WatchConfig() 静默失效。
- 运行
ls -l /etc/config/app.yaml看权限：若显示-r--------且进程非 root，fsnotify无法监听，需在 Pod spec 中加fsGroup: 1001或设defaultMode: 0644 - 某些发行版内核（如 CentOS 7）对 overlayfs 的 inotify 支持不完整，可改用 subPath 挂载单个文件，避免目录级事件丢失
- 别在 handler 里反复调用
viper.GetString("log.level")，应启动时提取并缓存到局部变量，否则每次调用都走 map 查找 + 锁，性能差还掩盖热更新效果 - 如果用
viper.WatchConfig()但没反应，先确认是否漏了viper.OnConfigChange()注册——没有它，事件回调根本不会执行
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
