viper.setconfigfile()易出事因其硬编码路径且不自动识别扩展名或回退，而addconfigpath+setconfigname支持多路径搜索和格式自动匹配；热加载需配合fsnotify手动注册onconfigchange回调并重读配置值。
直接用 viper.AddConfigPath() + viper.SetConfigName()，别碰 viper.SetConfigFile() —— 后者一写死路径，换环境就 panic。
为什么 viper.SetConfigFile() 容易出事
它只认你写的那一行绝对或相对路径，不自动猜扩展名，也不 fallback。比如代码里写 viper.SetConfigFile("./config.yaml")，但上线时配置被挂载到 /etc/myapp/config.yml，程序启动直接崩溃，连日志都来不及打。
-
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.WatchConfig() 默认不工作，必须手动集成 fsnotify。否则改了文件，Gin 进程完全无感。
Pandas 配置文件报告生成器
下载
使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。
- 先
import "github.com/fsnotify/fsnotify" - 调用
viper.WatchConfig()后，必须注册回调：viper.OnConfigChange(func(e fsnotify.Event) { ... }) - 注意：热加载只触发变更通知，你要自己在回调里重新读取值（如
viper.GetInt("port")），不能依赖旧变量缓存 - 开发期可开，生产环境慎用——文件系统事件在容器中可能不可靠，尤其用 ConfigMap 挂载时
配合 Gin 启动时加载配置的典型流程
别在 main() 开头就调 viper.ReadInConfig()，得先加路径、设名字、再读；失败要明确处理，不能静默忽略。
- 顺序不能乱：
viper.AddConfigPath()→viper.SetConfigName()→viper.SetConfigType()（可选）→viper.ReadInConfig() -
ReadInConfig()报错时，检查err是否为viper.ConfigFileNotFoundError，避免把路径错误当成其他异常 - Gin 启动前，用
viper.GetPort("server.port")或viper.GetString("database.dsn")提前校验关键字段是否存在、类型是否合法 - 敏感配置（如密码）不要硬编码进 YAML，应通过环境变量覆盖：
viper.AutomaticEnv()+viper.SetEnvPrefix("APP")
最常被跳过的一点：没验证配置加载结果是否真实生效。比如 viper.GetInt("port") 返回 0 不代表没读到，可能是配置里写的是字符串或字段名拼错了——务必在启动前打一行日志确认关键值。
