Viper 是 Gin 项目最稳妥易维护的配置方案，但默认不热加载，viper.WatchConfig() 必须手动配 fsnotify 才生效；应优先用 viper.AddConfigPath() + viper.SetConfigName() 实现多路径 fallback 和自动扩展名匹配，而非固定路径的 viper.SetConfigFile()。
直接说结论：Viper 是 Gin 项目里最稳妥、最易维护的配置方案，但默认不热加载，viper.WatchConfig() 必须手动配 fsnotify 才生效，否则改了配置文件也没用。
为什么不用 viper.SetConfigFile() 而要用 viper.AddConfigPath() + viper.SetConfigName()
因为后者支持多路径 fallback 和自动扩展名匹配（比如你设 SetConfigName("config")，它会依次尝试 config.yaml、config.yml、config.json），而前者只认死路径，一旦路径错或文件移动就 panic。生产环境常需适配不同部署方式（本地开发用 ./config.yaml，Docker 里挂载到 /etc/app/config.yaml），用 AddConfigPath() 可叠加多个路径：
viper.AddConfigPath("./config")viper.AddConfigPath("/etc/myapp")-
viper.AddConfigPath(".")（兜底当前目录）
顺序很重要：Viper 按添加顺序查找，第一个找到的配置文件即生效。
viper.Unmarshal() 和直接用 viper.GetString() 的取舍
结构体解码（viper.Unmarshal()）适合配置项多、有嵌套、需类型校验的场景；而单点取值（如 viper.GetString("db.host")）适合简单变量或临时调试。但注意：
- 结构体字段必须是 public（首字母大写），且加
yaml:"xxx"tag，否则解码为空 -
viper.Unmarshal()不会自动填充默认值，得先调viper.SetDefault() - 如果配置缺失某字段，
viper.Unmarshal()会静默置零（string 为空串，int 为 0），而viper.GetString()返回空字符串，容易掩盖错误
建议：核心配置（如 DB 连接参数）用结构体 + 显式校验；开关类配置（如 debug_mode: true）可直接用 viper.GetBool() 并配合 SetDefault()。
热加载失效的三个常见原因
写了 viper.WatchConfig() 却没反应？大概率卡在这三处：
- 没调
viper.OnConfigChange()回调 —— 仅 Watch 不够，必须注册处理函数，否则变更事件被丢弃 - 配置文件路径是相对路径，而进程工作目录不是你预期的（比如用
go run main.go时工作目录是项目根，但用 systemd 启动时可能是/）—— 建议用os.Getwd()打印确认 - Linux 下 inotify 限制，默认监听句柄数可能不足（尤其 Docker 容器内）—— 查看
/proc/sys/fs/inotify/max_user_watches，低于 1024 就容易漏事件
热加载时别直接重赋全局 DB 句柄，应重建连接并优雅关闭旧连接，否则 goroutine 泄漏或连接复用失败。
真正麻烦的不是读配置，而是当配置项之间存在依赖（比如 log_level 影响 zap.Config 构建，而 zap.Config 又要传给 Gin 的 Logger 中间件），这时结构体解码和初始化顺序就得仔细推演，稍不留神就 panic 在 InitConfig() 之前。
