Viper读不到config.yaml是因为未显式指定路径和扩展名；必须调用AddConfigPath设置搜索目录、SetConfigName指定无后缀文件名、SetConfigType声明格式，否则默认仅在当前目录查找config文件且不自动识别.yaml后缀。
为什么 Viper 读不到 config.yaml？路径和扩展名必须显式指定
常见错误是 viper.ReadInConfig() 报错 Config File "config" Not Found in "[.]"，本质是没告诉 Viper 去哪找、找哪个文件。Viper 不会自动扫描当前目录下所有 .yaml 文件，必须手动设置。
-
viper.SetConfigName("config")指定的是**文件名（不含后缀）**，不是路径 -
viper.SetConfigType("yaml")必须显式声明格式，即使文件是.yaml，Viper 也不会自动推断 -
viper.AddConfigPath("./config")才是真正设置搜索目录；多个路径可重复调用，Viper 按顺序查找 - 如果配置文件在
./configs/app.yaml，就该用viper.SetConfigName("app")+viper.AddConfigPath("./configs")
YAML/TOML/JSON 配置结构差异直接影响 Unmarshal 行为
不同格式对嵌套层级、空值、布尔值的解析规则不同，直接导致 viper.Unmarshal(&struct) 失败或字段为空。尤其注意 YAML 的缩进敏感性和 TOML 的数组写法。
- YAML 中
db:后必须换行+缩进，否则viper.GetString("db.host")返回空字符串 - TOML 中数组写法是
servers = ["127.0.0.1", "192.168.1.1"]，而 YAML 是servers: ["127.0.0.1", "192.168.1.1"]，结构体字段类型必须匹配 - JSON 不支持注释，但 YAML/TOML 支持；若配置里有
# port: 8080，用 JSON 解析会直接报错 - 布尔值在 YAML 写
debug: true没问题，但在 TOML 必须写debug = true（等号不能省）
热加载配置时 WatchConfig() 不生效的三个原因
viper.WatchConfig() 看似一行代码就能监听文件变更，但实际常因环境或权限问题静默失败，OnConfigChange 回调从不触发。
Pandas 配置文件报告生成器
下载
使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。
- Linux/macOS 下，若二进制被
docker run -v挂载配置文件，inotify 可能无法监听挂载点变化，需改用fsnotify的WithPoller模式 - Windows 上某些 IDE（如 Goland）编辑保存时可能先写临时文件再替换，导致 fsnotify 事件丢失，建议关闭 IDE 的“安全写入”选项
-
viper.Unmarshal(&Conf)若 struct 字段名与 YAML key 大小写不一致（如 YAML 是user_name，struct 字段是UserName），反序列化会静默跳过该字段，看起来像“没更新”
多环境配置（dev/prod）怎么避免硬编码判断逻辑
把 if env == "prod" 这类分支写死在 InitConfig() 里，既难测试又易出错。Viper 提供更干净的方案。
- 用
viper.AutomaticEnv()+viper.SetEnvPrefix("APP")，让APP_ENV=prod go run main.go自动切换配置源 - 文件命名按环境区分：
config-dev.yaml/config-prod.yaml，启动时通过--env=prod参数传入，再动态viper.SetConfigName("config-" + env) - 更推荐的方式：统一用
config.yaml，内部用 YAML anchor + merge（defaults: &defaults {port: 8080}），不同环境继承并覆盖字段
配置热加载不是开箱即用的功能，它依赖底层文件系统事件机制，而容器、IDE、甚至 macOS 的 FSEvents 都可能干扰。真正稳定的做法，是把配置变更视为一次轻量级服务重启，而不是强求实时生效。
