koanf的配置优先级由Load()调用顺序决定，后加载源递归合并覆盖先加载源；viper中SetDefault值不可被文件覆盖，AutomaticEnv须在SetEnvPrefix后调用，slice默认完全替换而非追加。
Go 语言没有内置配置合并逻辑，所谓“多源合并”只是你手动控制加载顺序 + 库的覆盖规则共同作用的结果。不理解这点，调试时永远在猜为什么 DB_HOST 没生效。
koanf 的 Load() 顺序就是优先级
koanf 不区分文件、环境变量或命令行的“天然等级”，只认 Load() 调用先后：后调用的递归合并进前一次结果里。这意味着顺序写错，整个覆盖逻辑就崩了。
- 先
k.Load(file.Provider("config.yaml"), yaml.Parser())—— 基础值 - 再
k.Load(env.Provider("APP_", "_", nil), nil)—— 环境变量覆盖部分键（如APP_DB_HOST→db.host） - 最后
k.Load(posflag.Provider(flags, ".", k), nil)—— 命令行参数兜底
常见错误：把命令行那步放最前，它立刻被后续 Load() 冲掉；或者漏掉 env.Provider，结果 k.String("db.host") 死活返回 config.yaml 里的旧值。
viper 的 SetDefault() 是“最低优先级里的最高者”
viper.SetDefault("log.level", "info") 一旦调用，后续 ReadInConfig() 就再也覆盖不了它——和直觉相反，它不是“默认 fallback”，而是“不可被文件覆盖的硬编码值”。
Pandas 配置文件报告生成器
下载
使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。
立即学习“go语言免费学习笔记（深入）”；
-
viper.AutomaticEnv()必须在viper.SetEnvPrefix("APP")之后调用，否则APP_LOG_LEVEL不会映射到log.level -
viper.BindPFlag("port", flag.Lookup("port"))必须在flag.Parse()之后执行，否则 flag 值还是空字符串 - 用
embed.FS读取配置字节流时，viper.SetConfigFile()完全无效，必须靠viper.SetConfigType("yaml")显式声明格式
嵌套 map 和 slice 的合并行为差异极大
不同库对结构体字段的处理逻辑完全不同，尤其当配置含 features: ["a", "b"] 这类 slice 时：
- koanf / viper / gorush：对基础类型（string/int/bool）直接覆盖，对嵌套 map 递归合并，但对 slice 默认是**完全替换**，不是追加
- go-spring：明确区分“叶子值覆盖”和“map 合并”，且将 slice 视为不可合并类型（完全替换），这点和 koanf 一致
- 别指望环境变量设
FEATURES=c,d就能让最终配置变成["a","b","c","d"]——实际结果就是["c","d"]
结构体字段零值？90% 是 tag 或导出问题
YAML/JSON 解析后字段全是零值，几乎从不因为配置内容写错，而是 Go 层面的访问限制：
- 字段名首字母小写（如
port int）→yaml.Unmarshal直接跳过，不报错也不赋值 - tag 写成
yaml:"Port"，但 YAML 里是port: 8080→ 匹配失败，留零值 - 嵌套结构漏了外层 tag，例如
Server ServerConfig `yaml:"server"`忘了这个`yaml:"server"`→ 整个子结构不会被解析 - YAML 文件用了 tab 缩进 →
yaml.v3默认 panic，加yaml.UnmarshalStrict才能捕获明确错误
真正容易被忽略的是：所有这些行为都发生在你调用 Unmarshal 或 ReadInConfig() 的那一瞬间，没有中间态可查——出问题只能回溯加载链和结构体定义，而不是看配置文件本身。
