Viper 是 Gin 项目最稳妥易维护的配置方案，但默认不热加载；viper.WatchConfig() 必须手动配 fsnotify 才生效；应优先用 viper.AddConfigPath() + viper.SetConfigName() 替代 viper.SetConfigFile()，因其支持多路径查找与扩展名 fallback，避免死路径导致 panic。
直接说结论：Viper 是 Gin 项目里最稳妥、最易维护的配置方案，但默认不热加载，viper.WatchConfig() 必须手动配 fsnotify 才生效；用 viper.AddConfigPath() + viper.SetConfigName() 替代 viper.SetConfigFile()，否则路径一错就 panic。
为什么不用 viper.SetConfigFile()
它只认死路径，不自动匹配扩展名，也不支持 fallback。比如你写 viper.SetConfigFile("./config.yaml")，但部署时文件被挂载到 /etc/app/config.yml，程序就直接 panic。
-
viper.AddConfigPath("./config")、viper.AddConfigPath("/etc/myapp")、viper.AddConfigPath(".")可叠加多个路径，按添加顺序查找 -
viper.SetConfigName("config")会自动尝试config.yaml→config.yml→config.json→config.toml - 开发时放
./config.yaml，Docker 启动时挂载/etc/myapp/，代码完全不用改
viper.Unmarshal() 和单点取值怎么选
结构体解码适合核心配置（如 DB、Redis），单点取值适合开关类或临时调试。
- 结构体字段必须首字母大写，且带
yaml:"db.host"tag，否则解码为空 -
viper.Unmarshal()不会填充默认值，得提前调viper.SetDefault("log.level", "info") - 字段缺失时，
viper.Unmarshal()静默置零（string为空串，int为 0），而viper.GetString("xxx")返回空字符串，容易掩盖错误 - 建议：DB 连接参数用结构体 + 显式校验；
debug_mode: true这类直接用viper.GetBool("app.debug")并设默认值
viper.WatchConfig() 热加载没反应？先查这三处
写了 WatchConfig() 却不生效，基本卡在这三个地方。
- 没注册回调：
viper.OnConfigChange()必须显式设置，否则变更事件被丢弃 - 工作目录不是你预期的：用
os.Getwd()打印确认，go run main.go和 systemd 启动时当前目录可能完全不同 - Linux inotify 句柄数不足：Docker 容器内常低于 1024，查
/proc/sys/fs/inotify/max_user_watches，不够就调高
热加载时别直接替换全局 DB 句柄
配置变了，DB 连接参数也变了，但不能简单 global.DB = newDB。
- 旧连接不会自动关闭，goroutine 泄漏风险高
- 应先调
oldDB.Close()，再建新连接，中间加锁防止并发冲突 - 如果用了连接池，记得同步更新
SetMaxOpenConns()、SetConnMaxLifetime()等参数
配置热加载真正难的不是监听文件变化，而是安全地切换运行时依赖——DB、Redis、HTTP client 等资源的重建与优雅下线，最容易被忽略。
