viper.WatchConfig() 无反应的根本原因是它仅触发通知而不自动更新配置，需配合SetConfigType()和OnConfigChange()回调才能生效，并确保结构体字段导出、tag正确、资源手动刷新。
viper.WatchConfig() 为什么没反应
根本原因：它只发通知，不干活。调了 viper.WatchConfig() 却没看到配置更新，大概率是因为没配 viper.SetConfigType()，也没注册 viper.OnConfigChange() 回调。
常见错误包括：
- 在
viper.ReadInConfig()之后才调viper.SetConfigType("yaml")—— 此时已晚，反序列化会静默失败或 panic - 监听路径设成目录（如
"./config"），结果被编辑器临时文件刷屏，回调被淹没 - 回调里只打日志，没调
viper.ReadInConfig()或viper.Unmarshal(&cfg)，viper 内部缓存压根没刷新 - 容器环境 inotify 句柄耗尽，
No space left on device实际是/proc/sys/fs/inotify/max_user_watches被打满，需启动时加--sysctl fs.inotify.max_user_watches=524288
热更新后结构体字段还是零值
不是 viper 没读，而是 mapstructure 解析跳过了字段。最常踩的坑是结构体字段没导出、tag 写错、大小写不匹配。
必须检查：
立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 字段名首字母大写（导出），小写字段哪怕有
json:"xxx"也会被忽略 - 统一用
mapstructure:"xxx"tag（比json:更适配 YAML/TOML），并开启下划线转驼峰：viper.SetEnvKeyReplacer(strings.NewReplacer("_", ".")) - YAML 里写
redis_url: redis://...，结构体字段就得是RedisURL string `mapstructure:"redis_url"`，不能写成RedisUrl或漏掉 tag - 首次加载失败必须
log.Fatal()或panic，空配置上线比加载失败更难排查
如何安全替换运行中的配置指针
直接赋值 globalCfg = &newCfg 是并发雷区。多个 goroutine 同时读写，可能读到“半更新”状态（Port 已变，DBURL 还是旧的）。
推荐方案是 sync/atomic.Value：
- 声明全局变量：
var globalConf atomic.Value - 初始化时存指针：
globalConf.Store(&defaultCfg) - 回调里解析完新配置后：
globalConf.Store(newCfg)（newCfg是全新*Config实例） - 业务代码固定写法：
conf := globalConf.Load().(*Config)，类型断言不能省，且建议判空 - 避免复用旧 map/slice 底层数组，新实例必须完全重建
配置变了，但数据库连接池没生效
热更新 ≠ 自动生效。viper 刷新了内存数据，但 sql.DB、http.Client 这些资源不会自己响应变更。
你必须主动处理：
-
db.SetMaxOpenConns()和SetMaxIdleConns()可运行时调，直接生效 -
http.Client.Timeout等字段不可变，只能新建*http.Client实例，再用atomic.StorePointer或互斥锁原子替换引用 - 日志级别可热更，但得调
zap.L().Sync()或cfg.AtomicLevel().SetLevel() - 路由规则、限流策略这类逻辑，不能硬编码在 handler 里，得封装成工厂函数，每次变更重建 handler 实例
真正的难点从来不在“怎么读新配置”，而在于“哪些组件要响应”和“怎么响应不中断请求”。这些没人替你写，全得在回调里显式补全。
