viper.watchconfig()仅触发回调，不自动重读、解析或刷新配置；必须在回调中依次调用readinconfig()、unmarshal()并原子替换指针，否则viper.get()和业务变量始终返回旧值。
viper.WatchConfig() 不会自动重读配置，只发回调
这是最常被误解的一点：调用 viper.WatchConfig() 后，改了文件，控制台可能打印“配置已更新”，但 viper.GetInt("port") 还是旧值。根本原因在于它只注册 fsnotify 监听、触发回调，**不读文件、不解析、不刷新内部缓存**。
必须在回调里显式做三件事：
- 第一行就调
viper.ReadInConfig()，否则内部 map 缓存仍是旧内容；错误必须检查：if err := viper.ReadInConfig(); err != nil { log.Printf("reload failed: %v", err); return } - 紧接着调
viper.Unmarshal(&newCfg)—— 它不做 diff，只把当前缓存值深拷贝进传入的结构体指针；不调它，你的结构体字段还是零值 -
viper.SetConfigType("yaml")（或"json"）必须在ReadInConfig()之前设置，否则类型不匹配会静默失败或 panic
监听路径写错导致“改了没反应”
现象是日志完全不触发，也没报错。常见原因不是代码写错，而是路径不一致：
- 如果用
viper.SetConfigFile("/etc/app/config.yaml")加载，viper.WatchConfig()默认监听的是当前工作目录下的config.yaml，不是你指定的绝对路径 - 编辑器（VS Code/Sublime）保存时默认 atomic write：先写临时文件再
rename，监听单个文件路径会失效；应监听父目录（如"./conf"），再用filepath.Base(event.Name) == "app.yaml"过滤 - 容器内挂载卷（
-v ./config.yaml:/app/config.yaml）时，fsnotify 无法穿透 overlayfs 层，监听必然静默失败；生产环境应把配置 COPY 进镜像，或改用远程配置中心
并发读配置时直接赋值会 panic
在 Golang 中使用 samber/hot 进行内存缓存，支持 LRU、LFU、TinyLFU、W‑TinyLFU、S3FIFO、ARC、TwoQueue、SIEVE、FIFO 等淘汰算法，提供 TTL、缓存加载器及分片功能。
热更新后写 globalCfg = &newCfg 或逐字段赋值（如 cfg.Port = newCfg.Port），在多 goroutine 场景下极易出现“半更新”状态：一个字段已变，另一个还是旧的，尤其结构体含嵌套 map 或指针时，nil panic 高发。
安全做法只有一种：原子切换指针
- 声明全局变量：
var globalConf atomic.Value - 初始化存默认配置：
globalConf.Store(&defaultCfg) - 回调中解析成功后：
globalConf.Store(&newCfg)（注意取地址） - 业务代码固定读法：
conf := globalConf.Load().(*Config)，类型断言不能省，且建议判空：if conf == nil { ... }
主线程退出导致监听失效
很多 demo 跑起来没反应，纯粹因为程序启动完立刻退出了。fsnotify 依赖后台 goroutine 持续接收事件，而 viper.WatchConfig() 本身不阻塞。
必须确保主 goroutine 长期存活：
- 启动 HTTP server：
http.ListenAndServe(":8080", nil) - 或简单阻塞：
select {}（仅开发测试用） - 或监听 OS 信号：
signal.Notify(ch, os.Interrupt, syscall.SIGTERM)，配合 graceful shutdown
真正难的不是监听到变更，而是让所有正在运行的 goroutine —— 从 DB 连接池、HTTP client timeout 到自定义限流器 —— 都能感知并响应新值。这需要你在 reload 回调里显式调用 db.SetMaxOpenConns()、logger.Level().SetLevel() 等接口，而不是指望“配置一换，组件自动跟着变”。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
